Trading system products and processes

ABSTRACT

A trading platform and trading method that allows access to additional pools of liquidity is described. Other embodiments are also described.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 16/293,917 filed on Mar. 6, 2019 which is a continuation ofU.S. patent application Ser. No. 13/614,758 filed Sep. 13, 2012 (nowU.S. Pat. No. 10,262,366 issued on Apr. 16, 2019), which is acontinuation of U.S. patent application Ser. No. 12/015,990 filed Jan.17, 2008 (now U.S. Pat. No. 8,285,629 issued on Oct. 9, 2012), whichclaims priority to provisional application 60/988,426, filed Nov. 15,2007, the disclosures of which are hereby incorporated by referenceherein in their entireties.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example computer system;

FIG. 2 illustrates an example trading system configured to perform oneor more trades;

FIG. 3 illustrates an example process that may be performed by one ormore trading systems;

FIG. 4 illustrates an example process that may be performed by aparticipant of a trading system;

FIG. 5 illustrates an example process that may be used to query aparticipant;

FIG. 6 illustrates an example process that may be used in responding toqueries;

FIG. 7 illustrates an example process that may be used for order entry;

FIG. 8 illustrates an example order entry interface;

FIG. 9 illustrates an example process that may be used to present orderquery information; and

FIG. 10 illustrates an example interface for presenting order queryinformation.

FIG. 11 is a high-level block diagram illustrating an electronic tradingmarketplace (ETM) environment according to an embodiment of the presentinvention;

FIG. 12 is a high-level block diagram illustrating more details of theETM;

FIG. 13 is a lower-level block diagram illustrating a trading systemlike those illustrated in FIG. 11;

FIG. 14 is a diagram illustrating a data record stored in the ordermanagement system (OMS) database to identify an order according to oneembodiment of the present invention;

FIG. 15 is a diagram illustrating a placement record preferably storedin the OMS database to indicate a placement of an order at a particularvenue;

FIG. 16 is a diagram illustrating an execution record preferably storedin the OMS database to indicate the execution of an order;

FIG. 17 is a flow diagram illustrating actions performed by anembodiment of the present invention when a trader logs on to the ETM;

FIG. 18 is a flow diagram illustrating actions performed by anembodiment of the present invention after a trader has logged on to theETM; and

FIG. 19 is a flow diagram illustrating actions performed by a preferredembodiment of the present invention when the OMS database is updated inresponse to a trade executed by the ETM.

DETAILED DESCRIPTION

The following sections I-X provide a guide to interpreting the presentapplication.

I. Terms

The term “product” means any machine, manufacture and/or composition ofmatter, unless expressly specified otherwise.

The term “process” means any process, algorithm, method or the like,unless expressly specified otherwise.

Each process (whether called a method, algorithm or otherwise)inherently includes one or more steps, and therefore all references to a“step” or “steps” of a process have an inherent antecedent basis in themere recitation of the term ‘process’ or a like term. Accordingly, anyreference in a claim to a ‘step’ or ‘steps’ of a process has sufficientantecedent basis.

The term “invention” and the like mean “the one or more inventionsdisclosed in this application”, unless expressly specified otherwise.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “one or more embodiments”, “someembodiments”, “certain embodiments”, “one embodiment”, “anotherembodiment” and the like mean “one or more (but not all) embodiments ofthe disclosed invention(s)”, unless expressly specified otherwise.

The term “variation” of an invention means an embodiment of theinvention, unless expressly specified otherwise.

A reference to “another embodiment” in describing an embodiment does notimply that the referenced embodiment is mutually exclusive with anotherembodiment (e.g., an embodiment described before the referencedembodiment), unless expressly specified otherwise.

The terms “including”, “comprising” and variations thereof mean“including but not limited to”, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expresslyspecified otherwise.

The term “plurality” means “two or more”, unless expressly specifiedotherwise.

The term “herein” means “in the present application, including anythingwhich may be incorporated by reference”, unless expressly specifiedotherwise.

The phrase “at least one of”, when such phrase modifies a plurality ofthings (such as an enumerated list of things) means any combination ofone or more of those things, unless expressly specified otherwise. Forexample, the phrase “at least one of a widget, a car and a wheel” meanseither (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car,(v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, acar and a wheel. The phrase “at least one of”, when such phrase modifiesa plurality of things does not mean “one of each of” the plurality ofthings.

Numerical terms such as “one”, “two”, etc. when used as cardinal numbersto indicate quantity of something (e.g., one widget, two widgets), meanthe quantity indicated by that numerical term, but do not mean at leastthe quantity indicated by that numerical term. For example, the phrase“one widget” does not mean “at least one widget”, and therefore thephrase “one widget” does not cover, e.g., two widgets.

The phrase “based on” does not mean “based only on”, unless expresslyspecified otherwise. In other words, the phrase “based on” describesboth “based only on” and “based at least on”. The phrase “based at leaston” is equivalent to the phrase “based at least in part on”.

The term “represent” and like terms are not exclusive, unless expresslyspecified otherwise. For example, the term “represents” do not mean“represents only”, unless expressly specified otherwise. In other words,the phrase “the data represents a credit card number” describes both“the data represents only a credit card number” and “the data representsa credit card number and the data also represents something else”.

The term “whereby” is used herein only to precede a clause or other setof words that express only the intended result, objective or consequenceof something that is previously and explicitly recited. Thus, when theterm “whereby” is used in a claim, the clause or other words that theterm “whereby” modifies do not establish specific further limitations ofthe claim or otherwise restricts the meaning or scope of the claim.

The term “e.g.” and like terms mean “for example”, and thus does notlimit the term or phrase it explains. For example, in the sentence “thecomputer sends data (e.g., instructions, a data structure) over theInternet”, the term “e.g.” explains that “instructions” are an exampleof “data” that the computer may send over the Internet, and alsoexplains that “a data structure” is an example of “data” that thecomputer may send over the Internet. However, both “instructions” and “adata structure” are merely examples of “data”, and other things besides“instructions” and “a data structure” can be “data”.

The term “respective” and like terms mean “taken individually”. Thus iftwo or more things have “respective” characteristics, then each suchthing has its own characteristic, and these characteristics can bedifferent from each other but need not be. For example, the phrase “eachof two machines has a respective function” means that the first suchmachine has a function and the second such machine has a function aswell. The function of the first machine may or may not be the same asthe function of the second machine.

The term “i.e.” and like terms mean “that is”, and thus limits the termor phrase it explains. For example, in the sentence “the computer sendsdata (i.e., instructions) over the Internet”, the term “i.e.” explainsthat “instructions” are the “data” that the computer sends over theInternet.

Any given numerical range shall include whole and fractions of numberswithin the range. For example, the range “1 to 10” shall be interpretedto specifically include whole numbers between 1 and 10 (e.g., 1, 2, 3,4, . . . 9) and non-whole numbers (e.g., 1.1, 1.2, . . . 1.9).

Where two or more terms or phrases are synonymous (e.g., because of anexplicit statement that the terms or phrases are synonymous), instancesof one such term/phrase does not mean instances of another suchterm/phrase must have a different meaning. For example, where astatement renders the meaning of “including” to be synonymous with“including but not limited to”, the mere usage of the phrase “includingbut not limited to” does not mean that the term “including” meanssomething other than “including but not limited to”.

The term “facilitating” and like terms may include any action or set ofactions which help to bring about a result. Throughout this disclosure,examples of facilitation may be given. Such examples should beinterpreted as non-limiting examples only.

An order query should be understood to include information that, wheninterpreted by a computer module, identifies an order for which a traderelated action is desired. Such information may be interpreted by thecomputer module for use in querying stored information such as adatabase of stored order information.

A computer modules should be understood to include any combination ofhardware and/or software.

A firm order should be understood to include an order for a financialinstrument, for which a system will execute a trade with a matchingorder without additional intervening authorization from an originator ofthe firm order.

A financial instrument should be understood to include an instrumentthat evinces ownership of dept or equity, and/or any derivative thereof,including equities, stocks, fixed income instruments, bonds, debentures,certificates of interest or deposit, warrants, options, futures,forwards, swaps, or generally any security.

Although some embodiments are described with reference to OrderManagement Systems, which are understood in the art, it should beunderstood that other embodiments may include an order informationsystem. An order information system should be understood any systemthrough which information about orders to purchase and/or sell financialinstruments is stored, including, for example, order management systems.

Two things should be understood to match if they share one or moreproperties. The exact properties shared may be different among variousembodiments. Some example properties may include, a type of financialinstrument (e.g., industry, capitalization, risk, etc.), a securityidentifier (e.g., stock symbol, etc.), an amount of shares, a price,etc.

A representation of a thing includes any indication from which a part ofan underlying thing may be derived.

Enabling should be understood to include allowing an action to occur. Anaction may be enabled by, for example, providing/activating a mechanism(e.g., a button or other control) through which the action may beperformed (e.g., by clicking a button or otherwise activating anothercontrol).

Binding acceptance of an order should be understood to include anacceptance of a trade fulfilling at least part of the order that doesnot allow for further intervention in the execution of the trade andwithout the ability to revoke the acceptance (e.g., without the abilityto revoke the acceptance in any way, without the ability to revoke theacceptance without a penalty).

Suppressing evidence should be understood to include attempting toprevent others from discovering evidence. Suppressing evidence of asituation or action may include not disseminating information about thesituation or action, disseminating false or misleading information aboutthe situation or action, disseminating false or mislead information atother times to obscure the dissemination of information about thesituation or action, and/or any other desired actions.

Facilitating execution of a trade should be understood to includeperforming any actions that help to bring about the execution of atrade. The actions may include, for example, actually executing thetrade, transmitting a request for the execution of the trade,transmitting any information that helps to bring about the trade, and/orany other actions.

A marketplace should be understood to include a platform through whichat least the following actions are performed: order execution isfacilitated, indications of orders are accepted, and matches for theorders are sought.

Applying a filter to a set of things should be understood to includegenerating a subset of the set of things in which each thing in thesubset has one or more desired properties.

A trade should be understood to fulfill part of an order for one or morethings if the trade includes transfers of ownership of at least aportion of the one of more thing in accordance with the order.

A participant system should be understood to include any system thatallows an order management system to interface with a marketplace.

II. Determining

The term “determining” and grammatical variants thereof (e.g., todetermine a price, determining a value, determine an object which meetsa certain criterion) is used in an extremely broad sense. The term“determining” encompasses a wide variety of actions and therefore“determining” can include calculating, computing, processing, deriving,investigating, looking up (e.g., looking up in a table, a database oranother data structure), ascertaining and the like. Also, “determining”can include receiving (e.g., receiving information), accessing (e.g.,accessing data in a memory) and the like. Also, “determining” caninclude resolving, selecting, choosing, establishing, and the like.

The term “determining” does not imply certainty or absolute precision,and therefore “determining” can include estimating, extrapolating,predicting, guessing and the like.

The term “determining” does not imply that mathematical processing mustbe performed, and does not imply that numerical methods must be used,and does not imply that an algorithm or process is used.

The term “determining” does not imply that any particular device must beused. For example, a computer need not necessarily perform thedetermining.

III. Forms of Sentences

Where a limitation of a first claim would cover one of a feature as wellas more than one of a feature (e.g., a limitation such as “at least onewidget” covers one widget as well as more than one widget), and where ina second claim that depends on the first claim, the second claim uses adefinite article “the” to refer to the limitation (e.g., “the widget”),this does not imply that the first claim covers only one of the feature,and this does not imply that the second claim covers only one of thefeature (e.g., “the widget” can cover both one widget and more than onewidget).

When an ordinal number (such as “first”, “second”, “third” and so on) isused as an adjective before a term, that ordinal number is used (unlessexpressly specified otherwise) merely to indicate a particular feature,such as to distinguish that particular feature from another feature thatis described by the same term or by a similar term. For example, a“first widget” may be so named merely to distinguish it from, e.g., a“second widget”. Thus, the mere usage of the ordinal numbers “first” and“second” before the term “widget” does not indicate any otherrelationship between the two widgets, and likewise does not indicate anyother characteristics of either or both widgets. For example, the mereusage of the ordinal numbers “first” and “second” before the term“widget” (1) does not indicate that either widget comes before or afterany other in order or location; (2) does not indicate that either widgetoccurs or acts before or after any other in time; and (3) does notindicate that either widget ranks above or below any other, as inimportance or quality. In addition, the mere usage of ordinal numbersdoes not define a numerical limit to the features identified with theordinal numbers. For example, the mere usage of the ordinal numbers“first” and “second” before the term “widget” does not indicate thatthere must be no more than two widgets.

When a single device, article or other product is described herein, morethan one device/article (whether or not they cooperate) mayalternatively be used in place of the single device/article that isdescribed. Accordingly, the functionality that is described as beingpossessed by a device may alternatively be possessed by more than onedevice/article (whether or not they cooperate).

Similarly, where more than one device, article or other product isdescribed herein (whether or not they cooperate), a singledevice/article may alternatively be used in place of the more than onedevice or article that is described. For example, a plurality ofcomputer-based devices may be substituted with a single computer-baseddevice. Accordingly, the various functionality that is described asbeing possessed by more than one device or article may alternatively bepossessed by a single device/article.

The functionality and/or the features of a single device that isdescribed may be alternatively embodied by one or more other deviceswhich are described but are not explicitly described as having suchfunctionality/features. Thus, other embodiments need not include thedescribed device itself, but rather can include the one or more otherdevices which would, in those other embodiments, have suchfunctionality/features.

IV. Disclosed Examples and Terminology are not Limiting

Neither the Title (set forth at the beginning of the first page of thepresent application) nor the Abstract (set forth at the end of thepresent application) is to be taken as limiting in any way as the scopeof the disclosed invention(s). An Abstract has been included in thisapplication merely because an Abstract of not more than 150 words isrequired under 37 C.F.R. § 1.72(b).

The title of the present application and headings of sections providedin the present application are for convenience only, and are not to betaken as limiting the disclosure in any way.

Numerous embodiments are described in the present application, and arepresented for illustrative purposes only. The described embodiments arenot, and are not intended to be, limiting in any sense. The presentlydisclosed invention(s) are widely applicable to numerous embodiments, asis readily apparent from the disclosure. One of ordinary skill in theart will recognize that the disclosed invention(s) may be practiced withvarious modifications and alterations, such as structural, logical,software, and electrical modifications. Although particular features ofthe disclosed invention(s) may be described with reference to one ormore particular embodiments and/or drawings, it should be understoodthat such features are not limited to usage in the one or moreparticular embodiments or drawings with reference to which they aredescribed, unless expressly specified otherwise.

No embodiment of method steps or product elements described in thepresent application constitutes the invention claimed herein, or isessential to the invention claimed herein, or is coextensive with theinvention claimed herein, except where it is either expressly stated tobe so in this specification or expressly recited in a claim.

The preambles of the claims that follow recite purposes, benefits andpossible uses of the claimed invention only and do not limit the claimedinvention.

The present disclosure is not a literal description of all embodimentsof the invention(s). Also, the present disclosure is not a listing offeatures of the invention(s) which must be present in all embodiments.

Devices that are described as in communication with each other need notbe in continuous communication with each other, unless expresslyspecified otherwise. On the contrary, such devices need only transmit toeach other as necessary or desirable, and may actually refrain fromexchanging data most of the time. For example, a machine incommunication with another machine via the Internet may not transmitdata to the other machine for long period of time (e.g. weeks at atime). In addition, devices that are in communication with each othermay communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components or features doesnot imply that all or even any of such components/features are required.On the contrary, a variety of optional components are described toillustrate the wide variety of possible embodiments of the presentinvention(s). Unless otherwise specified explicitly, nocomponent/feature is essential or required.

Although process steps, algorithms or the like may be described orclaimed in a particular sequential order, such processes may beconfigured to work in different orders. In other words, any sequence ororder of steps that may be explicitly described or claimed does notnecessarily indicate a requirement that the steps be performed in thatorder. The steps of processes described herein may be performed in anyorder possible. Further, some steps may be performed simultaneouslydespite being described or implied as occurring non-simultaneously(e.g., because one step is described after the other step). Moreover,the illustration of a process by its depiction in a drawing does notimply that the illustrated process is exclusive of other variations andmodifications thereto, does not imply that the illustrated process orany of its steps are necessary to the invention(s), and does not implythat the illustrated process is preferred.

Although a process may be described as including a plurality of steps,that does not imply that all or any of the steps are preferred,essential or required. Various other embodiments within the scope of thedescribed invention(s) include other processes that omit some or all ofthe described steps. Unless otherwise specified explicitly, no step isessential or required.

Although a process may be described singly or without reference to otherproducts or methods, in an embodiment the process may interact withother products or methods. For example, such interaction may includelinking one business model to another business model. Such interactionmay be provided to enhance the flexibility or desirability of theprocess.

Although a product may be described as including a plurality ofcomponents, aspects, qualities, characteristics and/or features, thatdoes not indicate that any or all of the plurality are preferred,essential or required. Various other embodiments within the scope of thedescribed invention(s) include other products that omit some or all ofthe described plurality.

An enumerated list of items (which may or may not be numbered) does notimply that any or all of the items are mutually exclusive, unlessexpressly specified otherwise. Likewise, an enumerated list of items(which may or may not be numbered) does not imply that any or all of theitems are comprehensive of any category, unless expressly specifiedotherwise. For example, the enumerated list “a computer, a laptop, aPDA” does not imply that any or all of the three items of that list aremutually exclusive and does not imply that any or all of the three itemsof that list are comprehensive of any category.

An enumerated list of items (which may or may not be numbered) does notimply that any or all of the items are equivalent to each other orreadily substituted for each other.

All embodiments are illustrative, and do not imply that the invention orany embodiments were made or performed, as the case may be.

V. Computing

It will be readily apparent to one of ordinary skill in the art that thevarious processes described herein may be implemented by, e.g.,appropriately programmed general purpose computers, special purposecomputers and computing devices. One or more such computers or computingdevices may be referred to as a computer system. FIG. 1 illustrates anexample computer system. The computer system comprises a plurality ofserver computers 101 and client computers 103. Typically a processor 105(e.g., one or more microprocessors, one or more microcontrollers, one ormore digital signal processors) will receive instructions (e.g., from amemory 107 or like device), and execute those instructions, therebyperforming one or more processes defined by those instructions.Instructions may be embodied in, e.g., one or more computer programs,one or more scripts.

A “processor” means one or more microprocessors, central processingunits (CPUs), computing devices, microcontrollers, digital signalprocessors, or like devices or any combination thereof, regardless ofthe architecture (e.g., chip-level multiprocessing/multi-core, RISC,CISC, Microprocessor without Interlocked Pipeline Stages, pipeliningconfiguration, simultaneous multithreading).

Thus a description of a process is likewise a description of anapparatus for performing the process. The apparatus that performs theprocess can include, e.g., a processor and those input devices andoutput devices that are appropriate to perform the process.

Further, programs that implement such methods (as well as other types ofdata) may be stored and transmitted using a variety of media (e.g.,computer readable media) in a number of manners. In some embodiments,hard-wired circuitry or custom hardware may be used in place of, or incombination with, some or all of the software instructions that canimplement the processes of various embodiments. Thus, variouscombinations of hardware and software may be used instead of softwareonly.

The term “computer-readable medium” refers to any medium, a plurality ofthe same, or a combination of different media, which participate inproviding data (e.g., instructions, data structures) which may be readby a computer, a processor or a like device. Such a medium may take manyforms, including but not limited to, non-volatile media, volatile media,and transmission media. Non-volatile media include, for example, opticalor magnetic disks 109 and other persistent memory. Volatile mediainclude dynamic random access memory (DRAM) 111, which typicallyconstitutes the main memory. Transmission media include coaxial cables,copper wire and fiber optics, including the wires that comprise a systembus coupled to the processor. Transmission media may include or conveyacoustic waves, light waves and electromagnetic emissions, such as thosegenerated during radio frequency (RF) and infrared (IR) datacommunications. Common forms of computer-readable media include, forexample, a floppy disk, a flexible disk, hard disk, magnetic tape, anyother magnetic medium, a CD-ROM, DVD, any other optical medium, punchcards, paper tape, any other physical medium with patterns of holes, aRAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip orcartridge, a carrier wave as described hereinafter, or any other mediumfrom which a computer can read.

Various forms of computer readable media may be involved in carryingdata (e.g. sequences of instructions) to a processor. For example, datamay be (i) delivered from RAM to a processor; (ii) carried over awireless transmission medium; (iii) formatted and/or transmittedaccording to numerous formats, standards or protocols, such as Ethernet(or IEEE 802.3), SAP, ATP, Bluetooth™, and TCP/IP, TDMA, CDMA, and 3G;and/or (iv) encrypted to ensure privacy or prevent fraud in any of avariety of ways well known in the art.

Thus a description of a process is likewise a description of acomputer-readable medium storing a program for performing the process.The computer-readable medium can store (in any appropriate format) thoseprogram elements which are appropriate to perform the method.

Just as the description of various steps in a process does not indicatethat all the described steps are required, embodiments of an apparatusinclude a computer/computing device operable to perform some (but notnecessarily all) of the described process.

Likewise, just as the description of various steps in a process does notindicate that all the described steps are required, embodiments of acomputer-readable medium storing a program or data structure include acomputer-readable medium storing a program that, when executed, cancause a processor to perform some (but not necessarily all) of thedescribed process.

A computer system may also include one or more input/output devices 113.Such input/output devices may include monitors, keyboards, mice, and rany other desired devices.

Some computer systems may include transmission medium 115, which may bereferred to as a communication network, that couples various internalcomponents of the computer system. Such a communication network may alsobe referred to in some implementations as a computer bus. Some computersystems may include a specialized input/output device 117 configured toconnect to an external communication network. Such a device may bereferred to as a network interface. The external communication networkmay include a LAN 119 and/or the Internet 121. In some implementations,an edge routing device 123 may operate between a LAN and another networklike the Internet 121. Such a device may include a firewall and/or anyother desired security mechanism.

Where databases are described, it will be understood by one of ordinaryskill in the art that (i) alternative database structures to thosedescribed may be readily employed, and (ii) other memory structuresbesides databases may be readily employed. Any illustrations ordescriptions of any sample databases presented herein are illustrativearrangements for stored representations of information. Any number ofother arrangements may be employed besides those suggested by, e.g.,tables illustrated in drawings or elsewhere. Similarly, any illustratedentries of the databases represent exemplary information only; one ofordinary skill in the art will understand that the number and content ofthe entries can be different from those described herein. Further,despite any depiction of the databases as tables, other formats(including relational databases, object-based models and/or distributeddatabases) could be used to store and manipulate the data typesdescribed herein. Likewise, object methods or behaviors of a databasecan be used to implement various processes, such as the describedherein. In addition, the databases may, in a known manner, be storedlocally or remotely from a device which accesses data in such adatabase.

Various embodiments can be configured to work in a network environmentincluding a computer that is in communication (e.g., via acommunications network) with one or more devices. The computer maycommunicate with the devices directly or indirectly, via any wired orwireless medium (e.g. the Internet, LAN, WAN or Ethernet, Token Ring, atelephone line, a cable line, a radio channel, an optical communicationsline, commercial on-line service providers, bulletin board systems, asatellite communications link, a combination of any of the above). Eachof the devices may themselves comprise computers or other computingdevices, such as those based on the Intel® Pentium®, Core, or Centrino™processor, that are adapted to communicate with the computer. Any numberand type of devices may be in communication with the computer.

In an embodiment, a server computer or centralized authority may not benecessary or desirable. For example, the present invention may, in anembodiment, be practiced on one or more devices without a centralauthority. In such an embodiment, any functions described herein asperformed by the server computer or data described as stored on theserver computer may instead be performed by or stored on one or moresuch devices.

Where a process is described, in an embodiment the process may operatewithout any user intervention. In another embodiment, the processincludes some human intervention (e.g., a step is performed by or withthe assistance of a human).

VI. Continuing Applications

The present disclosure provides, to one of ordinary skill in the art, anenabling description of several embodiments and/or inventions. Some ofthese embodiments and/or inventions may not be claimed in the presentapplication, but may nevertheless be claimed in one or more continuingapplications that claim the benefit of priority of the presentapplication.

Applicants intend to file additional applications to pursue patents forsubject matter that has been disclosed and enabled but not claimed inthe present application.

VII. 35 U.S.C. § 112, Paragraph 6

In a claim, a limitation of the claim which includes the phrase “meansfor” or the phrase “step for” means that 35 U.S.C. § 112, paragraph 6,applies to that limitation.

In a claim, a limitation of the claim which does not include the phrase“means for” or the phrase “step for” means that 35 U.S.C. § 112,paragraph 6 does not apply to that limitation, regardless of whetherthat limitation recites a function without recitation of structure,material or acts for performing that function. For example, in a claim,the mere use of the phrase “step of” or the phrase “steps of” inreferring to one or more steps of the claim or of another claim does notmean that 35 U.S.C. § 112, paragraph 6, applies to that step(s).

With respect to a means or a step for performing a specified function inaccordance with 35 U.S.C. § 112, paragraph 6, the correspondingstructure, material or acts described in the specification, andequivalents thereof, may perform additional functions as well as thespecified function.

Computers, processors, computing devices and like products arestructures that can perform a wide variety of functions. Such productscan be operable to perform a specified function by executing one or moreprograms, such as a program stored in a memory device of that product orin a memory device which that product accesses. Unless expresslyspecified otherwise, such a program need not be based on any particularalgorithm, such as any particular algorithm that might be disclosed inthe present application. It is well known to one of ordinary skill inthe art that a specified function may be implemented via differentalgorithms, and any of a number of different algorithms would be a meredesign choice for carrying out the specified function.

Therefore, with respect to a means or a step for performing a specifiedfunction in accordance with 35 U.S.C. § 112, paragraph 6, structurecorresponding to a specified function includes any product programmed toperform the specified function. Such structure includes programmedproducts which perform the function, regardless of whether such productis programmed with (i) a disclosed algorithm for performing thefunction, (ii) an algorithm that is similar to a disclosed algorithm, or(iii) a different algorithm for performing the function.

Where there is recited a means for performing a function that is amethod, one structure for performing this method includes a computingdevice (e.g., a general purpose computer) that is programmed and/orconfigured with appropriate hardware to perform that function.

Also includes a computing device (e.g., a general purpose computer) thatis programmed and/or configured with appropriate hardware to performthat function via other algorithms as would be understood by one ofordinary skill in the art.

VIII. Disclaimer

Numerous references to a particular embodiment does not indicate adisclaimer or disavowal of additional, different embodiments, andsimilarly references to the description of embodiments which all includea particular feature does not indicate a disclaimer or disavowal ofembodiments which do not include that particular feature. A cleardisclaimer or disavowal in the present application shall be prefaced bythe phrase “does not include” or by the phrase “cannot perform”.

IX. Incorporation by Reference

Any patent, patent application or other document referred to herein isincorporated by reference into this patent application as part of thepresent disclosure, but only for purposes of written description inaccordance with 35 U.S.C. § 112, paragraph 1 and enablement inaccordance with 35 U.S.C. § 112, paragraph 1, and should in no way beused to limit, define, or otherwise construe any term of the presentapplication where the present application, without such incorporation byreference, would not have failed to provide an ascertainable meaning,but rather would have allowed an ascertainable meaning for such term tobe provided. Thus, the person of ordinary skill in the art need not havebeen in any way limited by any embodiments provided in the reference

Any incorporation by reference does not, in and of itself, imply anyendorsement of, ratification of or acquiescence in any statements,opinions, arguments or characterizations contained in any incorporatedpatent, patent application or other document, unless explicitlyspecified otherwise in this patent application.

X. Prosecution History

In interpreting the present application (which includes the claims), oneof ordinary skill in the art shall refer to the prosecution history ofthe present application, but not to the prosecution history of any otherpatent or patent application, regardless of whether there are otherpatent applications that are considered related to the presentapplication, and regardless of whether there are other patentapplications that share a claim of priority with the presentapplication.

XI. Sample Embodiments

Information about orders for good or service may be tracked by an ordermanagement system (OMS). An order management system may include dataregarding desired, contemplated, open, completed, considered, ongoingand/or other order. One typical order management system used insecurities trading includes the Fidessa Order Management System.Although this order management system and embodiments below focuslargely on the trading of securities (e.g., stocks, bonds, futures,options, derivatives, etc.), it should be recognized that otherembodiments may be used in connection with the trading of any goodsand/or services whether tangible (e.g., food, oil, collectibles, etc.)or intangible (intellectual property rights, contract performance,etc.).

Information that is stored by an OMS may identify a specific securitythat is desired (e.g., by a user of the OMS, by a client of the user ofthe OMS, etc.), a type or class of security that is desired, an amountor range of amounts of a security that is desired, a desired price,price range, and/or pricing method to be used to buy the security, alimit on a desired price associated with a limit order for the security,a security to be sold, a price, price range, and/or pricing method to beused to sell a security, a security desired or available to be sold(e.g., long and/or short sale), an amount of a security to be sold,contingent buying and/or selling information (e.g., informationidentifying a purchase to be made if some contingent event occurs,information setting amounts based on a contingent price, etc.), and/orany other information.

Pricing policies may include any desired pricing policy supported by atrading system. In some embodiments, such a pricing policy may include,for example, midpoint pricing in which prices are based on a midpointbetween a national best offer and national best bid, limit pricing inwhich a maximum or minimum price level cannot be passed, midpointpricing subject to such a limit, volume weighted average pricing inwhich the weighted average price over a trading period is the bases ofthe price. Any other methods or combinations of pricing policies may beused.

Market liquidity, a measure a securities ability to be bought and/orsold readily through a market, is recognized as a factor that may affectprices at which securities are traded. For example, one may have a moredifficult time selling an illiquid security because potential buyers mayfear they will be unable to resell the security after purchase. Suchfear may artificially lower the price of the sale of the security fromthe true market value of the security to help alleviate the fears ofsuch potential buyers. Accordingly, a more liquid market may facilitatetrading of securities at their fair market values or closer to theirfair market values than they would be traded at in a less liquid market.

In some markets, information identifying orders (e.g., bids, offers,etc.) that is stored by order management systems, or otherwise storedinternally by a trading organization or trader, have not traditionallybeen thought of as liquidity available to the market. Rather, suchorders typically add to the liquidity of those markets only when theyare made public to the market so other traders in the market may actagainst those orders. Such secret orders may be referred to as “darkpools” or “dark books” of liquidity because they remain unseen by suchmarkets.

It is recognized that enabling trading to take place using such ordersmay improve the liquidity of a market and thereby allow more trades tooccur through a market and/or allow trades to occur at a price closer toor at a fair market value.

It is recognized that one problem that may be associated with using suchorders in a market includes a potential that information associated withthe existence of otherwise secret orders may be used to influence amarket and/or to diminish an advantage attributable to the originator ofthe information (e.g., some insight, knowledge, trading algorithm,etc.). In typical markets, when bids and offers match, a negotiation maytake place between a buyer and a seller before any transaction isfinalized. Such negotiations typically include revealing the existenceof a matching party, information about a matching order associated withthe matching party, and/or the identity of the matching party to bothparties involved in the negotiation. By revealing this information, thepotential to “game the market” (e.g., artificially affect a market usingknowledge of the existence of orders of other people) is increased andthe possibly secret knowledge embodied by the orders may be made public.For example, a trader may end a negotiation by refusing an order in anegotiation. The trader may subsequently use the knowledge that thematching party is interested in a transaction related to the security toincrease or decrease the price of the security by entering one or moreother orders at higher or lower prices and/or use the knowledge embodiedby the order to adjust otherwise adjust a trading strategy.

It is recognized that as the size of orders increases, the chances thata trader associated with such orders is trying to game the market maydecrease. Accordingly, it is recognized that trading large blocks ofliquidity may decrease the probability that gaming is occurring. It isalso recognized that if a trader agrees to have an order executedwithout a negotiation, without receiving notification before theexecution, and/or otherwise automatically, the chance that the trader istrying to game the market is also decrease. Furthermore, it isrecognized that if anonymity of trading partners is maintained for partor all of a trading exchange, the chances of gaming the market are alsoreduced. Accordingly, participants in securities markets, such as buyand/or sell side participants) may be more willing to participate inmarkets with one or more such characteristics. Further, suchparticipants may be more willing to allow orders present in OMS to addliquidity to such markets. Markets with such characteristics may, forexample, allow large blocks of securities to be moved relatively quietlycompared to traditional trading mechanisms.

It is recognized that in some markets, such as typical securitiesmarkets, participants exist in an asymmetrical relationship. Forexample, participants known as sell side firms in securities marketsgenerally act as retail brokers and researchers for investors.Participants known as buy side firms in securities markets generallyinclude investment institutions that tend to buy and/or sell largeamounts of securities for money-management purposes and keep informationabout their trading intentions secret. Accordingly, the desires of theseparticipants may not be identical. Some embodiments may be configured totreat differently participants with different characteristics in anattempt to balance desires of the different participants.

Some embodiments of a trading system may allow access to what might betraditionally untapped pools of liquidity (e.g., orders in OMS systems).Such systems may provide asymmetric access rules to such information toaccommodate desires and/or preferences of market participants. Suchsystems may include anonymity policies, order size restrictions,incentives, filtering policies, and/or automatic execution of types oforders to encourage participation.

Some embodiments may read information from an OMS or other source oforders associated with a buy side market participant. Informationregarding such orders may be used to match information from other marketparticipants with one or more element of anonymity, automatic orderexecution, and/or order size policy implementations. In someembodiments, the information may be narrowcast to potential counterparties for matching with orders associated with the OMS of thoseparties. Accordingly, market participants, such as sell sideparticipants and buy side participants can submit orders, both firmorders and OMS orders that add liquidity to a market, with a degree ofprivacy and/or a security that the market is not being gamed by otherparticipants.

In some embodiments, firm orders (i.e., orders for which participantsagree to automatic order execution with matching orders) may be viewedanonymously by those unlikely to abuse the information, and/or by nobodyat all. In some implementations, such participants may include buy sideparticipants who may view information about firm orders if a matchingorder exists in an OMS associated with a respective buy sideparticipant. In some implementations, such participants may includeparticipants for which matching firm orders exist (e.g., have beensubmitted to a trading system). By limiting the viewing of suchinformation, trading of high quality block liquidity using pools ofliquidity currently not available may be encouraged.

In some embodiments, control over one or more aspects of disclosinginformation about orders in an OMS may reside with buy side originatorsof the orders. In some embodiments, sell side participants or other buyside participants that enter a firm order matching an order in a buyside participant's OMS may only be notified of the existence of such amatching order if the buy side participant with the order in its OMSagrees to such notification, and/or agrees to an execution of a trade.In some embodiments, the sell side participants or other buy sideparticipants may not be notified of the identity of the buy sideparticipant at all, but rather only be notified that some matching orderwas found and/or executed.

Example Structures

FIG. 2 illustrates one example trading system configured to perform oneor more trades. As illustrated, the trading system may include aplurality of computer systems at one or more locations. The illustratedembodiment includes a central system along with a plurality of remotecomputer systems. Other embodiments may include different numbers,arrangements and/or types of computer systems. For example, someembodiments may include fewer or no remote computer systems. Some otherembodiments may include a more distributed or fully distributed systemsuch as one without any central system or with a limited central system.

The central system 201 or a place at which orders are executed may becalled a “marketplace”. In some embodiments, various actions, such asfirm order querying, firm order matching, providing indications of firmorders/firm order matches, receipt of indications that firm orderqueries/firm order matches exist and/or any other desired actions mayoccur, for example, upstream from such a marketplace.

As illustrated, the trading system may include a central system 201. Thecentral system 201 may include one or more computer systems, eachconfigured to perform one or more processes. Such computer systems mayreceive, transmit, and/or process information as desired. In someimplementations, the central system 201 may be configured to performactions including receiving information relating to orders (e.g., firmorders), matching firm orders, executing trades, facilitating theexecution of trades, clearing orders, facilitating the clearing oforders, communicating with remote systems, settling orders, reportingtrades, querying remote systems to determine if matching order exist,querying processes or databases to determine if matching orders exist,and/or any other desired actions.

In some embodiments, the central system 201 may be distributed among aplurality of regional hubs. Such distribution may allow a trading systemto span a very large geographic area through which a very large numberof trades may be routed. Such regional hubs may include duplicationand/or distribution of functionality.

In some embodiments, the central system 201 may be responsible forfacilitating one or more functions typically referred to as “backoffice” functions. For example, the central system 201 may facilitateclearing of trades, settling of trades, reporting of trades, creditchecking of participants, other functions required for compliance withrules and regulations, and/or any other desired functions.

In some embodiments, the central system 201 may include a firm ordermatching system. Such a system may be configured to determine if firmorders match other firm orders and/or perform other functions related tosuch firm order matching. In some embodiments, the central system mayinclude an order router matching module. Such a module may be configuredto route order queries to one or more participants and/or perform anydesired actions associated with OMS orders. In some embodiments, thecentral system may include a regulation NMS system. Such a system mayinterface with one or more other securities markets to find betterpricing options for an order. Such action may be required in someembodiments because of securities regulations.

In some embodiments, the central system may be coupled to one or moreremote systems by a communication network 203. The communication network203 may include the Internet, one or more local area networks, and/orany other desired communication medium. The communication network 203may allow the central system to transmit and/or receive information toand/or from remote systems, such as computer systems associated withmarket participants. In some embodiments, communication between systems,modules, processes, and/or programs may include the use of FinancialInformation eXchange messaging. Such messaging may be encrypted or notas desired. In some embodiments, one or more firewalls or other securitydevice may be included in the communication network 203.

In some embodiments, system 200 may include one or more sell sidecomputer systems, each indicated by 205. The sell side systems 205 mayinclude one or more trading computers configured to accept informationregarding security offers (e.g., firm orders to buy and/or sellsecurities). The sell side systems 205 may be configured to receive,send, and/or processes information. In some embodiments, the sell sidesystems 205 may be configured to transmit one or more indications ofsuch orders to the central system 201 over the communication network203. In some distributed embodiments, the sell side systems 205 may beconfigure to transfer information to one or more other sell side systems205 and/or buy side systems 207. In some embodiments, the sell sidesystems 205 may be configured to receive information identifying acompleted order execution (e.g., from the central system 201) and mayprovide an indication of such an indication to a user (e.g., through atrading interface). In some embodiments, the sell side systems 205 maybe configured to interact with the central system 201 or an otherwisedistributed system. In some embodiments, a separate computer system mayact as an interface between the central system 201 or otherwisedistributed system and the rest of the sell side system 205. Althoughthe sell side systems 205 are shown as a single system, it should berecognized that any number of computers may be used to perform anydesired functions of a sell side system.

Some embodiments may include one or more buy side systems, eachindicated at 207. In some embodiments, all or part of the buy sidesystems 207 may be located with a buy side market participant. In someembodiments, all or part of the buy side systems 207 may be distributedor located at a central location, such as with central system 201.

In some embodiments, the buy side systems 207 may include one or moretrader systems, each indicated at block 209. The trader systems 209 mayprovide an interface to one or more traders through which informationmay be obtained or provided. Traders, for example, may enter orderinformation and/or receive indications associated with orders through atrader systems 209.

In some embodiments, the buy side systems 207 may include one or moreOMS systems 211. The OMS systems 211 may perform one or more functionstypically performed by an OMS. Such functions may include storing orderinformation, providing order information to trader computers, and/or anyother desired functions. As mentioned above, one example OMS systemincludes the Fidessa OMS system.

In some embodiments, the buy side systems 207 may include one or moreparticipant systems 213. In some embodiments, the participant systems213 may act as an interface between the central system 201 or anotherwise distributed system and the rest of the buy side system 207. Insome embodiments, the participant system may perform function related totrading, such as storing order information, receiving firm orderqueries, executing orders, facilitating execution of orders, clearingorders, facilitating clearing of orders, transmitting order information,determining if matching orders exist, providing indication regardingorder queries, searching existing orders, determining if an order is afirm order or a OMS order, and/or any other desired functions.Participant systems may enhance the functionality of traditional OMSsystems by allowing otherwise unavailable pools of liquidity to becomeavailable to a market.

In some embodiments, participant systems 213 may query (e.g.,periodically, randomly, etc.) OMS systems 211 to generate a copy of anOMS database. In some embodiments, the OMS systems 211 may sendinformation to the participant systems 213 in response to such queriesand/or without any querying taking place. Such information may includeindications of orders in the OMS database (e.g., updates of priororders, changes to orders, deletions of orders, new orders, completedatabase copies, etc.) In some embodiments, a participant system 213 maydirectly access the OMS database (e.g., without the need to make a copy)of the OMS system 211, such as by querying the database. In still otherembodiments, the OMs system and participant system may be a singlesystem, and such distinctions may not be relevant.

In some embodiments, buy side order information may be maintained inconfidence on buy side systems, which may be located on respective buyside participants' premises. By so maintaining the information, buy sideparticipants may feel more secure about the use of such information fortrading and be less worried about potential information leakage.

In some embodiments, one or more software modules may act as part of anOMS system 211 to provide some or all buy side functionality. Suchmodules may exist in addition to and/or as an alternative to theparticipant system 213. For example, the module may include an update toan OMS software or a companion program to an OMS software program.

Although FIG. 2 shows OMS systems, participant systems and tradingsystems as separate systems, it should be understood that anyconfiguration of systems may be used. For example a single system mayoperate as all or part of any other systems (e.g., a single system mayact as an OMS system and a participant system, etc.) Furthermore,various systems may share information and/or distribute the performanceof functions. For example, an OMS system may maintain an order databasethat may be read by one or more or a trading system, a participantsystem, and/or any other desired system.

In some embodiments, one or more of the buy side or sell side systemsmay include mobile devices. Such mobile devices may include laptopcomputers, PDAs, cellular telephones, and/or any other desired mobiledevice.

In some embodiments one or more software modules may act as companionsand/or replacements to trading interface software and/or OMS software.Such companion or replacement software may include additional and/ordifferent options from traditional interface and/or OMS software.

Although FIG. 2 shows buy side systems 207 and sell side systems 205 asconnected to separate parts of communication network 203, it should beunderstood that such systems may be connected to a same network such asthe Internet or any other communication network.

Example System Processes

FIG. 3 illustrates an example process 300 that may begin at block 301.In some embodiments, process 300 may be performed by the central system201. In other embodiments, process 300 may be performed by one or moredistributed computer systems.

As indicated at block 303, process 300 may include receiving anindication of a firm order. In some embodiments, such an indication maybe considered a binding indication on the part of the firm ordersubmitter. For example, central system 201 may receive an indication ofsuch an order from a buy side system (e.g., 207) and/or a sell sidesystem (e.g., 205). Such orders may be entered, for example by a traderusing a trading interface at a buy or sell side firm. The indication ofthe firm order may identify that an originator of the order is committedto a transaction (e.g., a bid, offer, etc.). In some embodiments, anindication of an order may indicate an amount of a security to buy orsell, a time for a firm order to remain open, a price at or around whichto buy the security, a limit price, a pricing method, an orderidentifier, and/or any other information.

As indicated at block 305, process 300 may include determining if anymatching firm orders are available. A matching order may include anorder that includes complementary terms to the firm order. Such termsmay include a security, an amount, a price, a time frame, and/or anyother desired information. For example, the firm order may indicate that10,000 shares of eSpeed stock should be purchased at an average price of100.00 per share. A prior firm order may have been received thatindicates 10,000 shares of eSpeed stock should be sold at an averageprice of $100.00 per share. The prior eSpeed order may be determined tomatch the later eSpeed order in such a situation. In some embodiments,orders within a price range, below a maximum price, above a minimumprice, and/or matching in any other desired ways may also be determinedto be matching. In some embodiments, orders for a larger number ofsmaller number of shares may be determined to be matching. In someembodiments, an indication of a firm order may identify a minimum and/ormaximum order size/percentages for which other firm orders may bedetermined to be matching.

In some embodiments, multiple orders may be determined to be matchingaccording to some priority mechanism so that a total number of shares ofall matching orders sums to at least as much as a number indicated bythe firm order indication. In some embodiments, in which multiple ordersare determined to be matching, a priority may be assigned to some of theorders based one or more characteristics of the orders, an originator ofthe orders, and/or any other characteristic.

In some embodiments, a matching firm order may have been received from abuy or sell side system. Such a matching order may have been stored on amachine readable medium (e.g., a disk drive of the central system 201).Determining if a matching firm order has previously been received mayinclude searching a database or other listing of previously receivedfirm orders. Such a database may be keyed to allow quick lookup, such asby security identifier (e.g., stock symbol).

Some embodiments may include maintaining a listing of firm orders. Sucha listing may include a database. Maintaining the listing may includeadding newly received firm orders to the listing, deleting fulfilledfirm orders from the listing, deleting expired firm orders from thelisting, and/or any other desired actions.

As indicated at block 307, if one or more matching firm order isdetermined to exist, the execution of some or all of those matching firmorders may be facilitated to fulfill the received firm order. Each suchmatching orders may fully or partially fulfill the received firm order.Facilitating the execution may include performing an exchange of moneyfor a security, clearing such an exchange, transmitting information to aremote execution and/or clearing service, notifying participants, and/orany other desired action.

In some embodiments in which multiple matching orders exist, thematching orders may be matched to the received firm order based on anydesired prioritizing mechanism. Such prioritizing mechanism may includeprioritizing based on price of security, first come first serve,priority given to older and/or most active originators of orders, largeorders may be matched first, priority given to closest match in priceand/or size, a round robin system, and/or any other desired prioritizingmethod. In some embodiments, multiple orders may be combined together tofully fulfill as many existing offers as possible. In some embodiments,part of each matching order may be fulfilled. The part may correspond tosome characteristic of the order or order originator, such as ordersize, loyalty of originator, activeness of originator, actual pricecompared to desired price, etc.

In some embodiments, process 300 may end at block 309 if a matching firmorder is found. In some embodiments, if one or more matching firm ordersexist but do not completely fulfill the received firm order, executionof the matching firm order may be facilitated, and a remaining balanceof the firm order may be treated as if no matching firm order had beenfound (e.g., may continue as described below with a firm order thatincludes only the left over order amount).

In some embodiments, as indicated at block 311, process 300 may includequerying one or more participants to find a matching order. In someembodiments, querying the participants may include transmitting one ormore requests from a central system (e.g., 201) to a buy side system(e.g., 207). In other embodiments, querying the participants may includetransmitting requests from a computer of a distributed system to anothercomputer of the distributed system, such as from one buy sideparticipant to another, or one sell side participant to a buy sideparticipant, etc. In some embodiments, such querying may continue fromone participant to another participant in a tree like fashion in whichone or more participants queries one or more further participants whichmay themselves continue querying further participants and so on. Suchaction may be taken if no matching firm order was found or an incompleteset of matching firm orders was previously found as described above. Instill other embodiments, querying may include transmitting requests toother processes, threads, memory locations, portion of a computerprogram, etc. executing by a single system, such as central system 201or multiple systems, such as a distributed system.

Systems associated with market participants (e.g., buy side system 207,participant systems 205, 207) may be configured to accept requests anddetermine if matching OMS orders exist. In some situations, which arediscussed in more detail below, some such systems may respond to a queryindicating that a match exists. In some implementations such a responsemay include an indication that the trade has already been executedand/or cleared (e.g., by a remote system to which a request wastransmitted, some other system, etc.).

In some embodiments, the act of querying and/or some or all responsethat may be received may be concealed and/or otherwise suppressed froman originator of the firm order and/or any other individual. Forexample, if a negative response is received, such a response may not berevealed to the originator of the firm order. In some embodiments, asdiscussed below, only a positive response may be revealed. In someembodiments, negative response may be eliminated or otherwisesuppressed. By limiting responses, actions may be kept secret fromoriginators of the order and the participants may be granted anadditional level of anonymity, thereby encouraging them to participatein the trading system because the opportunity and/or chances to game themarket may be reduced.

As indicated at block 313, process 300 may include receiving additionalfirm orders from various other firm order sources such as buy sideand/or sell side participants. Such receipt of new firm orders may occursubstantially simultaneously as the querying of participants. Such newfirm orders may be compared with the received firm order from block 303to determine if they are matching, similar to the description above withrespect to block 305.

As indicated at block 315, process 300 may include determining if amatching order is found. Finding a matching order may include receivinga new firm order from another source and/or receiving a response from aparticipant that a matching order exists.

If no matching order is determined to exist, process 300 may loop backto block 311. In various embodiments, the participants may be queriedperiodically. The period may be any length, such as 30 seconds, 30minutes, a random length, a length based on some characteristic of atrader and/or order, etc. In various embodiments, participants may bequeried until either a match is found, a matching firm order isreceived, a time period associated with the firm order expires, the firmorder is revoked, and/or any other desired length of time.

If one or more matching orders is determined to exist, process 300 mayinclude facilitating execution of a trade fulfilling the firm order andthe one or more matching orders as indicated at block 317. In someembodiments, facilitating may include executing a trade, clearing atrade, transmitting indications that execution or clearing of a tradeshould be performed by a remote system, and/or any other desiredactions. In some embodiments, execution of the trade may occur at aremote server, such as one or more servers at which a firm order matchis found (e.g., a buy side system, etc.), and/or a central system, suchas central system 201.

In some embodiments, a matching order may not fulfill a whole firmorder. In such situations, process 300 may continue to search formatching orders, e.g., by querying remote servers and awaiting new firmorders in a loop to block 311.

In some embodiments, multiple matching orders may be found within arelatively short period of time. For example, multiple firm orders maybe received and/or multiple OMS orders may be found at participantswithin a relatively short period of time. Such a time period may be anyamount of time desired, such as 1 second, 1 minute, etc.

In various embodiments, order execution with such matching orders foundwithin such a short period of time may be based on some desired set ofpriorities. In such embodiments, matching orders found with in the shortperiod of time may be treated as if they were found simultaneously andexecuted based on some other priority mechanism. For example, firmorders may be executed first, or orders found through queryingparticipants may be executed first, first entered orders may be executedfirst, larger orders may be executed first, smaller orders may beexecuted first, older orders may be executed first, newer orders may beexecuted first, best customers may have their orders executed first,highest ranked customers may have their orders executed first, customerswilling to be charged a fee may have their orders executed first, and/orany other method may be used to determine execution order. In otherembodiments, order execution may be based strictly on the order in whichthe matching order is found.

Process 300 may end at block 319 after facilitation of the execution ofthe orders is complete. In some embodiments, one or more participants,such as originators of the orders may be notified of execution. In someembodiments, the order of acts may not be the same is indicated inprocess 300. In some embodiments, process 300 may include additionalactions, fewer actions, and/or different actions. Process 300 or asimilar process may be performed by any computer system or systems in acentralized and/or distributed manner.

Example Participant Processes

FIG. 4 illustrates an example process 400 that begins at block 401 andthat may be performed by a participant (e.g., by buy side system 207).In other embodiments, some or all of process 400 may be performed at acentralized location, such as by central system 201, or a distributedlocation, such as by sell side systems or buy side systems. Process 400may, in part, be performed to facilitate responses to queries and/or toprovide indications of firm orders, as those described above withrespect to process 300. In some embodiments, process 400 may beperformed by an OMS system, a separate participant system, a buy side orsell side trader's computer, or any other computer system such as oneconfigured to receive and process orders.

As indicated at block 403, process 400 may include receiving anindication of an order. Such an indication may be received, for example,from a trader entering information about desired trades through atrading interface. The indication may include an identification of aprice, an amount of a security to buy or sell, a time for an order toremain open, a price at or around which to buy the security, a limitprice, a pricing method, an order identifier, and/or any otherinformation.

As indicated at block 405, process 400 may include determining if theorder is a firm order. A firm order, as described above, may indicatethat an order should be executed substantially automatically. A OMSorder, may indicate that the information about the order is to remainsecret from other market participants and/or should not be automaticallyexecuted against. Some embodiments may not include a separate act ofdetermining a type of order. For example, in some embodiments, differentprocesses, threads, and/or systems may receive the different types oforders, so that the act of receiving the order itself identifies thetype of order. For example, a trader may use one interface to submit anOMS order (e.g., to an OMS system, to a participant system, etc.) anduse a different interface to submit a firm order (e.g., to a centralsystem, etc.). In some embodiments, a single program may be used tosubmit the different order types, and the program may make thedetermination (e.g., based on different buttons pressed, based ondifferent checkboxes selected, etc.).

As indicated at block 407, if the order is a firm order, process 400 mayinclude providing the indication of the order for firm order execution.Such providing may include transmitting information about the order tothe central system 201, or a distributed system. Such an order may bereceived by such system, which may attempt to execute the ordersubstantially automatically (e.g., using a process similar to process300). In some embodiments, such providing may include providing theinformation to a processing thread or program executed by one or morecomputing devices. Process 400 may end at block 409 if the order is afirm order. In other embodiments process 400 may continue to provideupdated information about the execution of the firm order, such asthrough an interface of a trading computer.

As indicated at block 411, if the order is not a firm order, process 400may include an act of storing information about the order. Storing theinformation may include storing the information on a machine readablemedium, such as in RAM, on a hard disk, etc. The medium may be partof/associated with one or more of an OMS system and/or a participantsystem. The information may be stored in one or more database tablesconfigured to store information about orders. Such a database table maybe arranged for easy searching of orders to determining if an incomingorder request matches any of the ordered stored in the database. Forexample, in some embodiments, the database may be keyed by a name of asecurity.

Some embodiments may include maintaining stored information. Suchinformation may be maintained similar to the maintenance of orderinformation in a typical OMS system. In some embodiments, maintenancemay include the actions of an OMS and/or a participant system.Maintenance may include updating orders executed in connection withmatching firm order queries. For example, order information may beremoved/updated when an order is fully or partially fulfilled, an orderexpires, an order is explicitly removed or updated by a trader, and/orfor any other desired reason.

As indicated at block 413, process 400 may include receive incoming firmorder queries. An incoming firm order query may indicate anidentification of a price, an amount of a security to buy or sell, atime for an order to remain open, a price at or around which to buy thesecurity, a limit price, a pricing method, an order identifier, and/orany other information. In some embodiments, such firm order queries maybe received from one or more computer systems performing a processsimilar to that shown in process 300. In some embodiments, the firmorder queries may include orders that would fulfill part or all of theOMS order. Such queries may be received at a participant system, an OMSsystem configured to perform some or all of the action of process 400,and/or any other desired location.

As indicated at block 415, process 400 may include determining that afirm order query matches the order. For example, a result from adatabase query that includes terms identified by the firm order query(e.g., security identifier, price, quantity, etc.) may return a positiveresult.

As indicated at block 417, process 400 may include attempting tofacilitate execution of a trade with the matching firm order query.Facilitating execution of a trade may include, for example, displayingan indication of the firm order to a trader through one or more tradinginterfaces, as discussed in more detail below, raising an alarm or otheraudible alert for such a trader, and/or any other desired action. Insome such embodiments, the trader may be asked to accept the matchingorder or reject the matching order. If the trader, in some embodiments,acceptance of the order, the system may execute a trade, forwardinformation for the trade to be executed and/or cleared by anothersystem, and/or perform any other desired action to further facilitateexecution of the trade.

In some embodiments, by keeping the OMS orders secret from other tradingparticipants, a trading system performing process 400 may encouragetraders to allow pools of liquidity that would typically remaininaccessible, such as orders in OMS systems, to be used to match againstfirm orders. This encouragement may be particularly important to buyside participants who may typically be protective of their orderinformation. Such use of OMS orders may increase liquidity in a marketusing such a process.

Process 400 may end at block 419, after facilitating execution of thetrade. In some embodiments, one or more participants, such asoriginators of the orders may be notified of execution. In someembodiments, stored information regarding the orders may be updated toreflect the order execution. In some embodiments, in which only part ofthe OMS order is fulfilled by the matching firm order, process 400 mayinclude receiving additional firm order queries and facilitatingexecution of those orders.

In some embodiments, the order of acts in process 400 may not be thesame is indicated in FIG. 4. In some embodiments, process 400 mayinclude additional actions, fewer actions, and/or different actions.Process 400 or a similar process may be performed by any computer systemor systems in a centralized and/or distributed manner. For example,process 400 may be performed by the participant systems 205, 207, by anOMS system configured to perform one or more parts of process 400,and/or by any other system. In some embodiments, process 400 may beperformed only in connection with a buy side participant.

Example Querying Processes

FIG. 5 illustrates an example process 500 that begins at block 501 andmay be used, in some embodiments, to perform, in part, querying ofparticipants, as indicated by block 311 of process 300 above. Process500 may be performed by a central computer system to query participantsfor matching orders, may be performed in a distributed fashion by aplurality of computer systems, and/or may be performed by any othercomputer systems. In some embodiments, such a process may be performed,in part or in whole, in a tree like distributed fashion in which someparticipants may query one or more child participants to search formatching orders.

As indicated at block 503, process 500 may include identifying one ormore participants. Participants may include one or more remote servers,one or more computer processes, threads, or programs. For example, insome embodiments, participants may include buy side systems. In otherembodiments, participants may include sell side systems, and/or othersystems. Identifying participants may include querying potentialparticipants in a list of participants, (e.g., pinging IP addresses,making function calls, etc.). In some embodiments, identifyingparticipants may include placing one or more items in a predefinedmemory location, querying a predefined memory location for informationabout participants, accessing a database or other listing ofparticipants, receiving an indication that a participant exists (e.g.,from the participant, from an administrator, etc.) and/or any otheractions desired. In some embodiments, the identified participants mayinclude child participants of a tree-like participant structure.

As indicated at block 505, process 500 may include receiving anindication of a firm order. Such a firm order may be substantiallysimilar to the firm order received at block 303 in process 300.

As indicated at block 507, process 500 may include transmitting requeststo the identified servers. Such requests may be substantially similar tothose discussed above with respect to block 311 in process 300. In someembodiments, as discussed above with respect to process 300, thereceived firm orders may be matched against other locally stored firmorders instead of or in addition to querying of participants asdiscussed with respect to process 300.

In some embodiments, participants may be arranged in a distributedfashion. For example in one embodiment, participants may be arranged ina tree-like fashion. In such an embodiment, a first participant mayquery one or more other participants. The other participants maydetermine if matches exist locally. If matches exist, the participantsmay return a positive indication (e.g., to the originating participant,the originator of the firm order, a marketplace, etc.). If no match isfound locally, the further participants may query additionalparticipants. The order of querying may be established based on anydesired priority mechanism (e.g., largest customers are queried first,premium customers queried first, highest ranked customers queried first,etc.). In some embodiments, a participant may query additionalparticipants regardless of whether a match is found locally.

As indicated at block 509, process 500 may include determining if aresponse was received from a queried participant. In some embodiments,determining if a response was received may include querying a port orsocket through which communication may be received from a communicationnetwork. In other embodiments, determining if a response is received mayinclude querying a register, memory location, process, thread, program,function and/or any other action.

In some embodiments, if no responses is received, process 500 may loopback to block 507 to send one or more additional requests. Any number ofrequests may be sent any number of times. Any period of time may passbetween transmission of requests (random, periodic, etc.). Process 500may continue to loop until a response is received, a matching firm orderis found otherwise, a time period expires, and/or any other eventoccurs.

In some embodiments, the participants queried at each loop may be thesame or different. For example, in some embodiments, an initial group ofparticipants may be queried first (e.g., a premium group ofparticipants, a group of good customers, a group of high volumecustomers, etc), and then after some period of time a second group ofparticipants may be queried. Any number of such subgroups may be queriedin such order.

As indicated at block 511, process 500 may include facilitatingexecution of a trade fulfilling a matching order in the response.Facilitating may include executing a trade, clearing a trade, forwardinginformation requests and/or any other desired action. In otherembodiments, a response may indicate that a trade has been or will beexecuted and/or cleared (e.g., by a remote system).

In some embodiments, a response may only be received if a match existsand/or a trader desires to execute a trade. Limiting response topositive responses may encourage participation because less informationis revealed from the participants. This may incentivize participants tomake orders available to a market to a great extent than in traditionalmarkets, thereby increasing the liquidity of the market.

Other embodiments may include receiving negative response when nomatching order exists and/or a trader does not desire to execute atrade.

In some embodiments, a response may be received for a trade that doesnot completely fulfill the firm order. In some implementations, afterexecution of such an order, process 500 may loop back to block 507 toquery participants again. Future queries of participants may include anupdated order with a requested amount decreased by the previous order.In other embodiments, such facilitation of order execution may belimited to complete orders (e.g., based on preferences indicated by anoriginator of the order, based on preferences of a trading system,etc.).

In some embodiments, multiple responses may be received at the same timeor within a relatively short time period. Orders received as such may betreated as if they were received at the same time. A priority mechanismmay be used to determine which of such orders is to be executed first.For example, an order associated with a high volume customer, a premiumcustomer, a long term customer, or a customer with any other desiredcharacteristic may be given higher or lower priority compared with otherorders. In some embodiments, largest or smallest orders may be givenpriority. In other embodiments, any desired priority mechanism may beused.

In some embodiments, process 500 may end at block 513. In someembodiments, process 500 may include notifying one or more traders ofthe execution. In some embodiments, process 500 may include additionalactions, fewer actions, and/or different actions. Process 500 or asimilar process may be performed by any computer system or systems in acentralized and/or distributed manner.

Example Passive Order Processes

Process 600 of FIG. 6 which begins at block 601 illustrates an exampleprocess that may be performed by one or more participants. Process 600may include actions similar to process 400 described above. In someembodiments, process 600 may be performed only by one or more buy sideparticipants.

As indicated at block 603, process 600 may include receiving one or moreindication of one or more orders. Such orders may include OMS orders asdiscussed above with respect to process 400. The orders may be storedaccordingly, as discussed with respect to block 411 so that queries maybe matched against them.

As indicated at block 605, process 600 may include receiving anindication of one or more firm order queries. Such firm order queriesmay be transmitted, for example, by an entity performing a processsimilar to process 500 and/or process 300 as discussed above.

As indicated at block 607, process 600 may include filtering firm orderqueries. Firm order queries may be filtered based on characteristics ofthe order (e.g., price, security, amount (e.g., minimum amount, maximumamount), etc.), characteristics of the originator of the order (e.g., arating of the originator, a type of the originator, specificoriginators, etc.), and/or orders queries may be filtered according toany other desired characteristics. In some embodiments, differentfilters may be applied to different types of securities. For example,large capitalization securities may have one set of filters applied andsmall capitalization securities may have a different set of filtersapplied. In some embodiments, specific securities (e.g., identified bystock symbol) may be filtered out or have a specific set of filtersapplied.

In some embodiments, filtering may allow a participant to filter queriesreceived from or sent to other participants. Filtering may be performedbased on any desired characteristics. Such characteristics may includecharacteristics that make the order less likely to be an orderassociated with gaming of the market. For example, in oneimplementations, a filter may block firm orders that do not meet aminimum size requirement, a minimum total dollar amount requirement,and/or any other desired characteristics.

In some embodiments, as another example, a participant may only desireto consider orders associated with originators with certaincharacteristics. Such characteristics may include characteristics thatmake an order less likely to be an order associated with gaming of themarket. For example, in one implementations, a filter may block ordersthat are from a particular class of traders (e.g., hedge funds, etc.),that are associated with a particular trader that has been identified bythe participant as being involved with gaming the market, that are notfrom a particular trusted set of participants, a from a set ofparticipants that were rated poorly by other participants, are from aparticipant without a history of trading, etc.

Some embodiments may include receiving an indication of desired filters.The indication may be received from one or more traders, participantsystems, or any other desired source. The indication may identify anydesired characteristics, combination of characteristics, exceptions tofilters, and/or any other information related to the filters.

The filters may be applied in a centralized fashions and/or adistributed fashion. For example, in some implementations, filters maybe applied before requests are transmitted (e.g., by a central system,by a distributed system, etc.). Applying the filters before transmittingrequests may decrease the amount of traffic associated with performingprocess 600. Conversely, performing such filtering before transmittingmay increase the amount of processing performed before transmitting andmay involve a participant revealing filtering preference they may notdesire to reveal to anyone, even a trading system administrator. Inother embodiments, filtering may occur locally to a participant. Byperforming such filtering locally, more traffic may be generated by atrading system, more processing may take place at participants, andfiltering options may remain private.

In some embodiments, participants may be filtered from receivingrequests based on the desires of a firm order submitter (e.g., by acentral system or other participant submitting queries, etc.). Suchparticipants may be filtered by identity, order availability, and/or anyother desired characteristic. Such filtering may occur for example, bythe participants themselves (e.g., by a participant system configured toperform such filtering in addition to, before, or otherwise inconnection with other participant functions), by a central system, by asubmitting system, and/or by any other desired system. In someembodiments, for example, a participant may not be provided with a queryif they do not have a matching firm order to fulfill a minimumpercentage of a firm order. In other embodiments, such information maynot be known until after a query is sent, and in such embodiments, amatch may only be determined to exist if the match meets the minimumpercentage. Filtering before transmitting queries may decrease an amountof traffic (e.g., TCP/IP packets) transmitted which may be snooped toreveal trading information, however, a malicious user may snoop suchqueries in an attempt to determine a filter setting.

In some embodiments, participant systems may transmit filteringinformation to a central system. Such information may be used to performthe filtering at the central system. Such information may also be usedto provide information to users entering firm orders, as describedbelow.

A trading system that allows such filtering may enable a participant toopen traditionally untapped pools of liquidity only to a certain subsetof traders. By allowing such limitations, the participant opening thatpool of liquidity (e.g., a set of orders in an OMS) may be moreconfident that the traders gaining access to those pools are not goingto use the pools of liquidity for malicious purposes (e.g., gaming themarket).

As indicated at block 609, process 600 may include determining if amatching order for the firm order query exists. Such determination mayinclude searching one or more database or other listings of OMS orders.The determination may be made at a same or different location as thefiltering. Determining may include searching a listing of orders in anOMS of a buy side participant. Such a listing may include all listedorders, a subset of listed orders identified as searchable by a trader,and/or any other orders.

As indicated at block 611, and 613, process 600 may end if it isdetermined that no matching order exists. Some embodiments may endwithout providing any indication that no order exists. By not providingspecifically identifying that no order exists, others (e.g., othertraders, participants, people snooping packets, etc.) may be unable todetermine if no order exists or no such response was sent for some otherreason (e.g., because a trader indicated that no trader should occur asdiscussed below, because a trade was filtered out, as discussed above,etc.). In some embodiments, no indication that the query was receivedmay be presented to a trader or trading system associated with theparticipant that received the query. By keeping such information secret,receivers of queries may be prevented from using the information thatthe firm order exists to game the market.

As indicated at blocks 611 and 615, if a firm order is determined toexist, process 600 may include providing an indication that a firm orderhas been received. Providing such an indication may include transmittinginformation over one or more networks from one computer system toanother computer system. Providing such an indication may includepresenting a user (e.g., a buy side trader associated with the OMS ordermatched) with one or more interfaces or icon identifying the firm order.Such an interface may include options to accept a firm order, reject afirm order, ignore a firm order, ignore all firm orders (e.g., for adesire period of time), and/or any other desired options. Such anindication may be considered a non-binding indication from the point ofview of the participant associated with the OMS in so much as arecipient (e.g., a participant associated with the matching OMS order)is not bound to fulfill any order based on the indication. However, anoriginator of the firm order may still be bound to fulfill the order ifthe recipient of the indication chooses to accept the order.

In some embodiments, ignoring a firm order may result in a participantopting out of receiving/matching using firm order queries for a minimumamount of time. Such an opt out time may encourage participants toaccept firm order queries. The time may vary based on characteristics ofthe order and/or participants.

In some embodiments, a user may select various options regardingignoring future indications. For example, a user may select thatindications should be ignored unless a price associated with the firmorder is at a certain level, a firm order has some desiredcharacteristic, ignore until a certain time, ignore for a certain amountof time, ignore until the end of the day, etc.

In some embodiments, evidence that a user has selected to ignore anindication may be suppressed. For example, the information maymaintained in confidence at a participant system, may be kept inconfidence at a central system, or may otherwise be kept secret. Inimplementations where different options for ignoring an indication mayselected, evidence regarding some or all of the information regardingthe options may also be suppressed.

As indicated at block 617, process 600 may include awaiting a responsefrom such an indication. Some implementations may include receiving aresponse and determining if the response is a positive or negativeresponse. In other implementations a response may not be received or mayonly be received if the response is a positive response. In someembodiments, the amount of time to be awaited may be indicated to atrader. In some embodiments, the amount of time may vary based on one ormore desired characteristics of a security, a participant, an originatorand/or other desired entity.

As indicated at block 619, process 600 may include determining if apositive response is received. Determining if a response is a positiveresponse may include determining which if any mouse buttons werepressed, which if any keyboard buttons were pressed, which interfacecontrol if any was selected, and/or any other determination of apossible entry of intent, if any.

As indicated in block 621, process 600 may end if a positive response isnot received. In some embodiments after a period of awaiting, apresumptive default response may be entered. In some implementationssuch a default response may include a negative response. In someembodiments, an operator of an interface (e.g., a trader, anadministrator, etc.) may determine the appropriate amount of time and/orthe appropriate default command.

As indicated at block 623, if a positive response is received, process600 may include facilitating a trade fulfilling at least part of thematching order and at least part of the firm order. Facilitating thetrade may include executing the trade, clear the trade, transmittinginformation so that the trade is executed and cleared remotely and/orany other desired actions. In some implementations, facilitating mayinclude providing a positive response (e.g., to a central server, to abuy side and/or sell side participant, etc.). The recipient of thepositive response may further facilitate the execution of the trade if atrade fulfilling the firm order has not already been executed.Transmission of a positive response may be considered a bindingindication of a trade in so much as the participant associated with theOMs order may be bound to fulfill the matching firm order by theindication. In some embodiments, the binding may be conditioned on thefirm order not having been fulfilled previously, not on actions of theparticipant.

In some implementations, process 600 may include receiving an updateregarding the facilitation of the execution, such an update may includereceiving an indication that the execution was completed or that theexecution was not completed. In some implementations, a trade may bepartially completed and an update may indicate that the trade waspartially completed. For example, a trade may be partially completed ifwhen the positive response is received, only part of the firm order isstill awaiting execution, and the OMS order includes a larger volume fortrade. In such a situation, a trade may be cancelled in someembodiments, in other embodiments, a the OMS order may be executed tothe extent that the firm order remains, and in indication to that extentmay be transmitted to the participants, in still other embodiments, anoriginator of the OMS order may be contacted with the updated firm orderinformation, and/or any other action may be taken.

Process 600 may end at block 625. Process 600 may include notifying oneor more participants of a result of the facilitation of the execution ofthe trade. In some embodiments, process 600 may include additionalactions, fewer actions, and/or different actions. Process 600 or asimilar process may be performed by any computer system or systems in acentralized and/or distributed manner Process 600 may be performed byone or more computer systems in a centralized and/or distributedfashion.

Example Order Entry Processes

FIG. 7 illustrates an example process 700 that begins at block 701 andthat may involve interfaces used in some embodiments. Process 700 may beperformed in part, for example, by an OMS, a trading terminal, and/orany other computer system.

As indicated at block 703, process 700 may include providing aninterface through which one or more of a firm order and/or a OMS ordermay be entered. Such an interface may allow a user to enter informationidentifying a security, a pricing policy, a price, an amount, and/or anyother information about a desired trade.

FIG. 8 illustrate one example interface through which a user may enterorder information. Through such an interface a user may be able to enterorder types, a security desired, a pricing policy, a time in force, alimit, a minimum fill amount, a increment fill amount, an amount, and/orany other desired options. In some embodiments a same or similarinterface may be used for entry of one or more of firm order and OMSorder information.

Such a trading interface may illustrate information about apercentage/number of participants that may view a firm order queryassociated with an entered order as indicated at 801. This informationmay be based on filters established by the participants to filter outorders as described above. Such information may be collected by acentral system (e.g., from participant systems). One characteristic thatmay be frequently used to filter orders includes size of the order. Thepercentage/number of participants may reflect the total number ofparticipants willing to accept orders with all characteristics exceptsize and the number willing to accept with the size characteristic.Accordingly, order originators may adjust their order size to increaseor decrease the number of participants queried.

As indicated in block 705, process 700 may include receiving informationabout an entered order. The information may include information enteredthrough the provided interface and/or any other information (e.g.,default information, identification information, etc.).

As indicated at block 707 process 700 may include determining if theorder is a firm order. Determining if the order is a firm order mayinclude determining characteristics of an input signal, an interfacecontrol, and/or any other information. Some implementations may notinclude such a determination, but rather an interface, program,computer, etc. at which the indication is received or through whichinformation related to the indication is entered may identify the typewithout a separate action being taken.

As indicated at block 709, if the order is a firm order, process 700 mayinclude transmitting (e.g., to a central system, a distributed system,etc.) an indication of the firm order for automatic execution againstmatching orders (e.g., matching firm orders previously or latersubmitted, OMS orders, etc.). Process 700 may then end at block 711. Insome implementation, process 700 may also include receiving informationabout a matching order and displaying that information through one ormore interfaces.

As indicated at block 713, if the order is determined not to be a firmorder, process 700 may include transmitting a representation of theorder to be matched against incoming order queries e.g., by a processsuch as process 400. Transmitting may include providing to a differentprocess, thread, memory location, etc. In other embodiments, a sameprogram thread server may perform query matching, providing interfaces,receiving order information, and/or any other desired acts. As indicatedat block 715, process 700 may then end.

In some embodiments, process 700 may include receiving information aboutthe order, such as whether matching queries are received, etc. In someimplementations, process 700 may be performed, for example by a tradingcomputer, an OMS system, a central system, and/or a participant server.In some embodiments, process 700 may include additional actions, feweractions, and/or different actions. Process 700 or a similar process maybe performed by any computer system or systems in a centralized and/ordistributed manner Process 700 may be performed by one or more computersystems in a centralized and/or distributed fashion. In someembodiments, entering OMS orders in such a process may be limited to buyside participants of a market.

Example Passive Order Query Processes

FIG. 9 illustrates an example process 900 that begins at block 901.Process 900 may be performed, for example, by a buy side system, sellside system, and/or any other computer system. In some implementations,a participant server, a trader's computer, an OMS, and/or any othercomputer system may perform one or more actions associated with process900 and/or a similar process.

As indicated at block 903, process 900 may include receiving anindication that a firm order matches a OMS order. Such an indication maybe received from one or more OMS systems, participant servers, centralservers, buy side systems, sell side systems, computer programs,computer processes, computer threads, memory locations, networkinterfaces, and/or other desired sources.

As indicated at block 905, process 900 may include providing aninterface, icon and/or other indication that a matching order exists.FIG. 10 illustrates an example interface that may be used as such anindication in some embodiments. Such an interface, as illustrated, maydisplay some details of a matching order. Such an interface may allow atrader to indicate a positive response to the order or a negativeresponse to the order (e.g., by operating a control, such as a button).

Process 900 as indicated at block 907 may include determining if apositive response is received with some time period. In someembodiments, the period of time may include a default time period, anamount of time according to a user profile, an amount of time accordingto terms of the firm order, an amount of time determined in part by asize and/or dollar value of the order, and/or any other desired amountof time. In some implementations, receiving a positive response mayinclude receiving an indication that a control was selected. If apositive response is not received, process 900 may end at block 909.

As indicated at block 911, if a positive response is received, process900 may include transmitting a request to execute a trade fulfilling atleast part of the firm order and at least part of the matching order.Other embodiments may include otherwise facilitating the execution ofsuch a trade (e.g., executing the trade, clearing the trade, etc.)

Process 900 may end at block 913. Other embodiments of process 900 mayinclude receiving information about the execution of the trade,displaying information about such execution, displaying terms associatedwith a trade, displaying information about an originator of a firmorder, updating/maintaining stored order information and/or any otherdesired actions.

In some embodiments, multiple firm orders may match a OMS order. In suchembodiments, an indication of each such matching order may be provided.In some embodiments, the indications may be ordered according to apreference mechanism. Such preference mechanism may include orderingbased on preferences of an order originator, an indication receiver, acomputer system administrator, and/or any other preferences of anyindividual regarding any characteristics of an order, computer system,trade, etc. In some implementations, rather than providing separateindications, indications may be pooled into a single indication. Suchpooling may include combining multiple firm orders according to somepreference mechanism so that the firm orders fulfill the matching order.If additional firm orders exist, some implementations may separatelyprovide information about such firm orders. In some implementations,even if indications are pooled, an interface may be provided that allowsa user to access information and enter information (e.g., acceptance oforders) about individual orders.

In some embodiments, process 900 may include additional actions, feweractions, and/or different actions. Process 900 or a similar process maybe performed by any computer system or systems in a centralized and/ordistributed manner Process 900 may be performed by one or more computersystems in a centralized and/or distributed fashion. In someembodiments, only buy side participants may receive firm order queriesfor matching against OMS orders.

Processes 300-700 and 900 are arranged to provide convenientillustration of concepts disclosed herein. It should be recognized thatno such processes need be performed at all.

Encryption

In various embodiments, some or all communication may be encrypted. Invarious embodiments, some or all information stored in various media maybe encrypted. In some embodiments, comparisons among information may bemade in an encrypted form. In other embodiments, encrypted data may beunencrypted before a comparison occurs.

In some embodiments, an encryption algorithm such as the well-known PGP,RSA encryption method may be used for communication among participants,computer systems, etc. Advances in quantum computing may make suchencryption less secure in the future. Some embodiments, therefore mayinclude use of quantum key encryption algorithms designed to overcomesuch vulnerability and or other future proof encryption algorithms.

User Types

In some embodiments, different users of a system (e.g., central system,buy side system, sell side system, trader computer, etc.) may haveaccess to different options. Because a market may be asymmetrical,providing asymmetrical options to such user types may best capture adynamic of the market. For example, in a security trading market,participants may be divided into four example categories which mayinclude hedge funds, investors, brokers, and verified naturals. Itshould be recognized that other embodiments may include different,additional, alternative, fewer, and/or no categories of users.

Referring to the example four category embodiment, investors may includetraders that trade on behalf of their own accounts (e.g., individuals).Hedge funds may include organizations exempt from standard securitiesregulation that typically seek high returns for accredited investors.Brokers may include originations that may trade on behalf of others asregulated by standard securities laws. Verified naturals may includebrokers that are not acting one behalf of their own proprietaryaccounts. To become a verified natural, a broker may be required toprovide proof that they are not trading on behalf of their ownproprietary accounts. In some implementations, a single user may act asmore than one type of user at various times. For example, a broker mayact as a broker in some situations and a verified natural in othersituations. Options and treatment given to such different categories mayreflect a likelihood that the participants may be gaming the market.

In some embodiments, information provided to users may depend upon acategory or type of user. For example, users may be limited to receivingcertain firm order queries, accepting certain firm order matches, etc.based on their category. In one implementation, for example, only buyside participants only may receive firm order queries. In suchsituations, information about possible trade executions with OMS ordersmay not be provided to sell side participants until and unless a tradeis accepted by a buy side participant and/or executed.

In some embodiments, as discussed above, rebates and charges may begiven. In some embodiments, such rebates and/or charges may depend on acategory of participant. For example, in some implementations, investorsmay be given a rebate for submitting firm orders. In otherimplementations, anyone submitting a firm order may be given a rebate.In some implementations, brokers may be charged a fee for each time aOMS order matches a firm order query. In some implementations, brokerscan opt out of having their firm orders matched against other brokersfirm orders because of pricing rebate that allows brokers to be paid forsubmitting firm orders.

In some embodiments, size or other characteristics of a participant mayaffect a participants options. Some implementations, for example, may belimited to large participants, others to small participants, others mayallow all sized participants.

Possible Negotiation

Although some embodiments described above execute trades without anegotiation between participants in the trade (e.g., with only a buy orreject/ignore option presented to participants with matching OMSorders), some embodiments may include a negotiation. Such negotiationmay be limited in some embodiments to preserve anonymity, encourageentering of OMS orders, and/or limit the possibility of gaming themarket.

In some embodiments, for example, where there are multiple matchingorders, a negotiation to determine the counter party that is willing toadjust their offer the most may be performed.

In some embodiments, if user accepts a matching firm order found from aquery, the user and/or the originator of the firm order may be presentedwith an option to trade more of the security. By selecting a control inan interface that activates such an option, a negotiation may beginbetween the two participants. Such a negotiation may include asking ifthe other party agrees to trade more, the terms of such a trade, etc.Such negotiation may limit the probability of gaming the market sincethe participants may already be aware of each other from the priortrade.

Rebate

Some embodiments may include providing rebates or charging fees to tradeparticipants. Such fees and/or rebates may be arranged to incentivizeparticipation in certain aspects of a trading system. For example, insome embodiments, when an order is executed based on a firm ordermatched with a OMS order, the participant that submitted the firm ordermay receive a rebate, and the participant associated with the OMS ordermay be charged a fee.

Types of Trades

Some embodiments may support various types of trades. Such trades mayinclude buying securities, selling securities, short selling securities,and/or any other desired types of trades. In some embodiments in which ashort sell of a security is performed, a location of apurchased/borrowed security may be required before a short sell ordermay be completed.

Tracking Users

Some embodiments may include tracking information about one or moreparticipants. For example, a trade history, a number of trades, a typeof trades, characteristics of trades, etc. may be tracked for buy and/orsell side participants. In some information, a participant may view someor all of such information about itself and/or about other participants.In some embodiments, such information may be used to generate a ratingof a participant. Such a rating may be used, for example, as a filter ofparticipants querying a participant server.

It should be recognized that while embodiments described hereingenerally included a computer-human interactions (e.g., through aninterface), other embodiments may be performed completely though acomputer (e.g., a computer may respond to firm order queries, etc.).

It should also be recognized that while embodiments described hereingenerally included various securities trading, other embodiments may beused to trade any desired goods or services.

XII. Other Embodiments

What follows are embodiments, not claims:

A method comprising:

receiving an order query, the order query identifying a firm order for afinancial instrument;

determining if the firm order matches an order stored by an ordermanagement system; and

only if the firm order is determined to match the order associated withthe order management system, providing a representation of the firmorder, and enabling a binding acceptance of the firm order.

The method of claim A, further comprising:

if the firm order is determined not to match the order associated withthe order management system, suppressing evidence of the determination.

The method of claim A, further comprising:

receiving an indication of the binding acceptance; and

facilitating execution of a trade fulfilling at least part of the firmorder.

The method of claim C, in which facilitating includes at least one ofexecuting the trade, and transmitting a request to a remote system toexecute the trade.

The method of claim A, further comprising:

if an indication of the binding acceptance is not received, suppressingevidence of the determination of the match.

The method of claim A, in which the order query is received from amarketplace.

The method of claim A, in which determining if the firm order matchesthe order stored by the order management system includes applying afilter to the firm order.

The method of claim A, in which the representation is provided to atrader associated with the order management system.

A method comprising:

receiving a firm order for a financial instrument;

transmitting an order query identifying the firm order to each of aplurality of trading systems for comparison with orders associated witha respective order management system of each trading system;

only if a determination that a matching order is stored in a respectiveorder management system is made, and the firm order is accepted,receiving a reply from at least one of the plurality of trading systemsidentifying acceptance of the firm order; and

in response to receiving the reply, facilitating execution of a tradefulfilling at least part of the firm order.

The method of claim I, in which each of the plurality of trading systemsincludes at least one of a respective order management system, and arespective participant system coupled to the respective order managementsystem.

The method of claim I, in which receiving the firm order, transmittingthe order query, receiving the reply, and facilitating execution areperformed by a marketplace.

The method of claim I, in which the firm order is accepted by a traderassociated with the respective order management system.

The method of claim I, in which facilitating execution includes at leastone of executing the trade, and transmitting a request to a remotesystem to execute the trade.

A method comprising:

receiving a first firm order for a financial instrument;

determining if a second firm order matching the first firm order hasbeen received;

if the second firm order has been received, facilitating execution of atrade fulfilling at least part of the first firm order and at least partof the second firm order; and

if the second firm order has not been received, transmitting an orderquery identifying the first firm order to each of a plurality of tradingsystems, each trading system configured to determine if the first firmorder matches an order associated with a respective order managementsystem, and to attempt to facilitate a trade if the first firm ordermatches the order associated with the respective order managementsystem.

The method of claim N, in which facilitating the trade includesproviding a representation of the firm order configured to allow abinding acceptance of the firm order.

The method of claim N, in which each of the plurality of trading systemsincludes at least one of a respective order management system, and arespective participant system coupled to the respective order managementsystem.

The method of claim N, in which the actions are performed at amarketplace.

The method of claim N, in which facilitating execution includes at leastone of executing the trade, and transmitting a request to a remotesystem to execute the trade.

A system comprising:

a computer system configured to transmit order queries identifying firmorders to each of a plurality of trading systems,

in which each of the plurality of trading systems is configured todetermine if the firm order matches an order associated with arespective order management system and to attempt to facilitate a tradeif the firm order matches the order associated with the respective ordermanagement system.

The method of claim S, in which each of the plurality of trading systemsincludes at least one of a respective order management system, and arespective participant system coupled to the respective order managementsystem.

The method of claim S, in which facilitating execution includes at leastone of executing the trade, and transmitting a request to a remotesystem to execute the trade.

A method comprising:

submitting a firm order to a system of claim S.

A method comprising:

submitting an order for storage by an order management system, in whichthe order management system is configured to allow comparison of firmorder queries with orders stored by the order management system, and

receiving an indication that a firm order query matches the order, theindication allowing a binding acceptance of the firm order query.

The method of claim W, further comprising transmitting an indication ofthe binding acceptance to a marketplace.

The method of claim W, in which the binding acceptance includes anindication that a trade should be automatically executed.

XIII. Miscellaneous Information

Numbering of elements in the below section may not match to numbering ofelements in the previous sections. This section provides additionaldisclosure of relevant material, and should not be interpreted to limitany prior disclosures.

Although computers are heavily used to facilitate trading of securities,manual intervention is still required at certain steps in the tradingprocess. For example, most traders at institutional investmentmanagement firms record their orders to purchase or sell securities incomputerized order management systems (OMS's). However, one or moretraders at each firm must manually review the orders in the OMS andattempt to fill the orders by contacting one or more marketintermediaries. Typically, the traders transmit the orders in the OMS bytelephone or separate data entry links to registered broker-dealers forthe securities, to electronic marketplaces that trade the securities, orto other market intermediaries. Accordingly, manual effort is requiredto actually execute the orders in the OMS.

One problem arising from this manual effort is that institutionaltraders cannot execute trades involving large quantities of securitieswithout adversely affecting the market price of the securities. Forexample, institutional traders often need to trade large quantities ofsecurities due to the continuing need of investment managers to respondto changes in market conditions by altering the contents of theirinvestment portfolios. As these portfolios increase in size due toincreased investor activity, the corresponding quantity of securities tobe traded in order to achieve a similar portfolio balance alsoincreases. Market impact costs, or adverse costs resulting from theinstitutional traders' activities, rise in such circumstances becauselocating parties with whom to trade such large quantities of securitiesbecomes more difficult for the market intermediaries.

Moreover, if the market intermediaries become aware that aninstitutional firm wants to, say, sell a large block of a particularequity security, this awareness is likely to lower the sale price thatthe institutional firm can obtain due to the normal processes of supplyand demand. The effect is also likely to be exacerbated by speculationfrom others with knowledge of the order as to why the particularinvestor wishes to sell such a large quantity of the security.Similarly, if market intermediaries become aware of the fact than aninstitutional firm wants to buy a large block of a particular equitysecurity, this awareness will likely increase the purchase price thatthe institutional firm will have to pay. This adverse effect on price isfurther exacerbated by the fact that traditional market intermediariestrade for their own accounts.

One strategy commonly employed by institutional traders to offset marketimpact costs is to spread out trade orders for a large quantity of asecurity into small orders each handled by a different marketintermediary, sometimes over several trading days. Of course, thisstrategy brings about its own problems in that the market price canchange significantly during this extended trading period due to theunforeseeable activities of others.

Another strategy that may be employed is to spread the orders for thesecurity among one or more electronic marketplaces. However, the tradersmust manually transmit each order to the electronic marketplaces using atelephone or a separate data entry link. The fact that the traders needto perform these extra steps, which include duplicate entry of basicorder data already recorded in the OMS, causes many traders to use theseelectronic marketplaces infrequently, and to supply the marketplaceswith only a small subset of the total orders. As a result, theseelectronic marketplaces often lack the liquidity required by a trader totimely execute orders.

The lack of integration between the OMS and the electronic marketplacesalso poses problems when an institutional trader wishes to trade aparticular security simultaneously within an electronic marketplace and,for example, over the telephone with a traditional broker. For example,some electronic marketplaces attempt to find matches at only specifictime intervals. If a trader wishes to buy 100,000 shares of IBM, and hasplaced an order for half that amount in an electronic marketplace, thetrader will not know how much, if any, IBM stock was purchased untilafter the next scheduled match attempt. In the meantime, the traderpotentially could have purchased more than 50,000 shares from a brokerover the phone at a better price.

Therefore, there is a need in the art for an electronic tradingmarketplace that does not require any manual intervention by traders orother parties, offers anonymity, and offers a high amount of liquidity.

The present invention addresses the above need by providing for theautomated transmission of orders (i.e., without manual traderintervention) from the various order management systems (OMS's) used byinvestment management firms or other entities having trading systems toan electronic trading marketplace (ETM). A firm with a trading systemstores information about orders in an OMS to manage its order flow, tomonitor the initiation, placement, and execution of orders, and forrelated purposes. Software providing the functionality of an OMS is wellknown in the art.

OMS interfacing modules (OIMs) at the firms automatically transmitorders from the OMS's to the ETM and preferably update the OMS's inresponse to orders executed at the ETM. Traders can communicate with theETM to anonymously negotiate trades of securities. As used herein, a“security” is an ownership or creditorship interest, such as a stockcertificate, bond, or any other financial instrument, contract ortransaction, such as a forward, futures, option, put, call, collar,swap, or currency contract on any security. This description uses theterm “security” for convenience but it should be understood that theterm covers financial instruments generally.

The ETM includes an OMS data integration module (ODIM) for receiving andprocessing data representative of orders received from the OIMs. In apreferred embodiment, the data from the OIMs are provided to the ETM ina standardized format that requires little processing by the ODIM. Theorders processed by the ODIM are stored in an ETM database.

A negotiation module in the ETM supports negotiations between traders.In one embodiment, an indications module transmits orders received bythe ETM among the traders based upon filtering criteria established bythe traders and/or the ETM. These orders are transmitted among thetraders in the form of non-binding indications. Based upon theseindications, traders at one institution can enter into negotiations withtraders at other institutions, through the negotiation module of theETM. In one embodiment, at least parts of the negotiations are conductedanonymously.

A trader authentication module authorizes and authenticates traders wholog into the ETM in order to perform trading negotiations and/or otherfunctions. A transaction history module records transactions performedby the ETM in the ETM database. The transaction history module alsopreferably records other data processed by the ETM including, forexample, the orders received from and sent to the trading systems andthe conducted negotiations.

A typical trading system at an investment management firm or otherentity at which trading is performed includes a number of workstationscoupled to an OMS server via a network, with a trader at eachworkstation. Each workstation preferably executes a trader OMSinteraction module (TOIM) for facilitating interactions between thetrader's workstation and the OMS server. In one embodiment of thepresent invention, the TOIM allows a trader to add, delete, or modifyopen or contemplated orders stored in the OMS database. The OMS, whichincludes the OMS server, OMS database, and TOIM, is typically providedby an OMS vendor, though some firms have developed their own OMS's.

In connection with the present invention, each workstation alsopreferably executes an ETM interaction module (EIM) for facilitatinginteractions with the ETM. The EIM allows a trader to send informationto the ETM and view and respond to information received from the ETM.Typically, this information includes information about the trader'sindications, information about other traders' indications, and orderstransmitted to and received by a trader during a negotiation.

The OMS database holds data representative of open, contemplated, orcompleted orders to buy and/or sell securities by traders using thetrading system. The OIM is in communication with the OMS database andthe ETM. An OMS database integration module in the OIM reads datarecords stored in the OMS database and, in a preferred embodiment, alsocreates and modifies data records stored in the OMS database uponexecution of a trade through the ETM. In one embodiment, the OMSdatabase interaction module directly accesses the OMS database and inanother embodiment it sends commands to an application programminginterface (API) in the OMS for accessing the database.

The OIM also includes an ETM communication module for communicating withthe ETM. In one embodiment, the ETM communication module providesselected data records in the OMS database to the ETM and, in a preferredembodiment, receives data and/or instructions from the ETM regardingchanges to make to the OMS database. In addition, the OIM preferablyincludes a data record conversion module for modifying the format ofdata records sent to the ETM and/or received from the ETM. The OIM alsopreferably includes a filtering module for filtering out specifiedorders by security type, security name, order type, order price, orderquantity, or other category, so that those orders are not transmitted tothe ETM.

Preferably, the OIM transmits to the ETM data records in the OMSdatabase relating to a trader's orders when the trader logs on to theETM. Once the OIM determines that the trader has logged on to the ETM,the OIM retrieves data records about that trader's orders suitable fortransmission to the ETM from the OMS database. In one embodiment, theOIM converts the data records retrieved from the OMS database into astandardized format understood by the ETM. In another embodiment, thisfunctionality is part of the ETM.

After a trader has logged on to the ETM, the OIM determines whether thecontents of the OMS database have changed. If the OMS database haschanged, the OIM determines whether the change should be transmitted tothe ETM. In one embodiment, the OIM continues to determine whether thecontents of the OMS database have changed between the time that a traderlogs on to the ETM and the time that the ETM commences trading. Inanother embodiment, the OIM does not commence making this determinationuntil the time that the ETM commences trading.

Because typical OMS's are complex and multi-featured, and becausesecurities of types not handled by the ETM may be traded using the OMS,some changes to the OMS database do not necessitate a transmission ofupdated data to the ETM. The OIM preferably transmits changes to thedatabase to the ETM if the changes represent new or modified orders.

The OIM preferably updates the database in response to informationreceived from the ETM indicating executed trades or other information.In a preferred embodiment, if an execution occurred in the ETM involvingan order in the OMS associated with the OIM, the OIM receivesinformation from the ETM describing the execution. This informationincludes, for example, the type, amount, and price of securities traded,the time of execution, and/or information identifying the original orderin the OMS database on which the execution was based. The OIM convertsthe received information about the execution into the format used by theOMS and updates the OMS database accordingly. As a result of thesesteps, the OMS is updated automatically and transparently to reflectexecutions performed at the ETM. The executions appear to the OMS astypical trades conducted at another broker, so no special functionalityneeds to be added to the OMS in order to interact with the ETM beyondthat functionality described herein.

FIG. 11 is a high-level block diagram illustrating an electronic tradingmarketplace (ETM) environment according to an embodiment of the presentinvention;

FIG. 12 is a high-level block diagram illustrating more details of theETM;

FIG. 13 is a lower-level block diagram illustrating a trading systemlike those illustrated in FIG. 11;

FIG. 14 is a diagram illustrating a data record stored in the ordermanagement system (OMS) database to identify an order according to oneembodiment of the present invention;

FIG. 15 is a diagram illustrating a placement record preferably storedin the OMS database to indicate a placement of an order at a particularvenue;

FIG. 16 is a diagram illustrating an execution record preferably storedin the OMS database to indicate the execution of an order;

FIG. 17 is a flow diagram illustrating actions performed by anembodiment of the present invention when a trader logs on to the ETM;

FIG. 18 is a flow diagram illustrating actions performed by anembodiment of the present invention after a trader has logged on to theETM; and

FIG. 19 is a flow diagram illustrating actions performed by a preferredembodiment of the present invention when the OMS database is updated inresponse to a trade executed by the ETM.

FIG. 11 is a high-level block diagram illustrating an electronic tradingmarketplace (ETM) environment according to an embodiment of the presentinvention. An ETM 110 is in communication with three trading systems112A, 112B, 112C. Although only three trading systems 112 areillustrated, embodiments of the present invention can have many more (orfewer) trading systems 112 in communication with the ETM 110. FIG. 11illustrates only three trading systems 112 in order to enhance theclarity of this description.

The trading systems are used by investment management firms or otherentities that have established a relationship with the ETM 110. Thetrading systems 112 communicate with the ETM 110 to facilitate thetrading of securities. As used herein, a “security” is any ownership orcreditorship interest, such as a stock certificate or bond, or any otherfinancial instrument, contract, or transaction, such as a forward,futures, option, put, call, collar, swap, or currency contract. Thisdefinition includes, for example, any note, stock, bond, debenture,certificate of interest or participation in any profit-sharing agreementor in any oil, gas, or other mineral royalty or lease, any collateraltrust certificate, investment contract, voting-trust certificate,certificate of deposit, any put, call, straddle, option, or privilege onany of the foregoing, or group or index of securities (including anyinterest therein or based on the value thereof). This list is notall-inclusive. For purposes of clarity, this description will describethe trading of stock.

Within each trading system 112 is a database 114A, 114B, 114C associatedwith an order management system (OMS). Each OMS database 114 holds datarepresentative of open, contemplated, or completed orders to buy and/orsell securities (collectively referred to herein as “orders forsecurities”) by traders using the trading system 112. For example,assume that the database 114A of trading system 112A contains orders tosell 50,000 shares of DELL and 75,000 shares of MSFT and orders to buy25,000 shares of CPQ and 100,000 shares of IBM. Also assume that thedatabase 114B of trading system 112B contains orders to sell 30,000shares of CPQ and buy 62,000 shares of T.

The orders in the OMS databases 114 are automatically transmitted to theETM 110. Likewise, any changes in the orders, such as modificationsand/or withdrawals, are automatically transmitted to the ETM 110. Asused herein, the term “automatically” means that the associated actionis performed without any human or manual intervention. Thus, there is noneed for traders to specifically request that individual orders in theOMS databases 114 are transmitted to the ETM 110; orders in thedatabases are sent to the ETM 110 without the traders' input (subject tofiltering criteria).

Preferably, the ETM 110 anonymously transmits information about atrader's orders to other traders using the ETM, subject to filtering inaccordance with filtering criteria established by the traders and/or theETM. Moreover, the ETM 110 preferably manages anonymous negotiationsbetween traders using the trading systems 112 for the purpose ofexecuting the orders and sends data about the completed trades to theOMS's of the traders involved in the transaction.

Thus, one embodiment of the present invention selectively broadcastsinformation about the orders received by the ETM 110 from the database114A of trading system 112A to the other trading systems 112B, 112C.Likewise, the ETM 110 selectively broadcasts information about theorders received from the database 114B of trading system 112B to theother trading systems 112A, 112C. If the traders desire such a trade,the ETM 110 will facilitate the anonymous negotiation and sale of 25,000shares of CPQ from a trader using trading system 112B to a trader usingtrading system 112A.

Data is communicated between the trading systems 112 and the ETM 110using interfacing links 116A, 116B, 116C. Any known interfacingtechnologies can be used to effectuate these links, including, but notlimited to, transmission control protocol/Internet protocol (TCP/IP),satellite, cellular, and/or radio frequency (RF) links, or somecombination thereof. The links may pass through one or more intermediatedata processing systems, such as telephone switches or Internet servers,before reaching the ETM 110 or a trading system 112. In embodimentswhere data travels over shared links, such as embodiments where datatravels over the public Internet, the data is preferably encrypted usinga secure protocol, such as the secure sockets layer (SSL).

FIG. 12 is a high-level block diagram illustrating more details of theETM 110. Those of skill in the art will recognize that FIG. 12illustrates only one possible embodiment of the ETM 110. Obviously,different combinations of hardware and software can be used to providethe functionality of the ETM 110 described herein.

Data received by the ETM 110 from the trading systems 112 over theinterfacing links 116 are received by a firewall 210. As is known in theart, the firewall 210 preferably prevents unauthorized users fromgaining access to the rest of the ETM 110 and monitors transfers of datato and from the network.

Data that pass through the firewall 210 are received by one or moremodules that perform the functionality of the ETM 110. As used herein,the term “module” refers to machine-executable code and/or data, but mayalso include associated circuitry, such as processing circuitry, as wellas data storage areas, and/or any other software or hardware. Thus, itwill be appreciated that one or a combination of hardware and software,such as a computer system executing software for performing thefunctionality of the modules, may implement each of the modules shown inFIG. 12. It will also be appreciated by those skilled in the art thatthe ETM 110 may comprise one or more other types of modules, circuitry,etc., not shown in FIG. 12 in order to avoid unnecessarily obscuringunderstanding of the invention. For instance, the ETM 110 may includeone or more microprocessors, network connection circuitry, and/or datastorage areas, such as read-only memory (ROM), random-access memory(RAM), CDROM, DVD, tape drive, hard disk (HD), and/or other types ofstorage areas. It will also be appreciated that the functionality ofmultiple modules described herein can be combined into a single moduleand the functionality of a single module can be split or shared amongmultiple modules. Moreover, alternative embodiments of the presentinvention can lack one or more of the modules described herein and/orhave modules not described herein.

The ETM 110 preferably includes an OMS data integration module (ODIM)212. The ODIM 212 receives and processes data representative of ordersreceived from the OMS databases 114 in the trading systems 112. In apreferred embodiment, the data from the OMS databases 114 are providedto the ETM 110 in a standardized format that requires little processingby the ODIM 212. In an alternative embodiment, the data from the OMSdatabases 114 are provided to the ETM 110 in one or more differentformats depending upon factors such as the type of OMS used by thetrading systems 112, the types of interfacing links supplying the datato the ETM, the type of security or orders to which the data pertains,and the like. In this latter embodiment, the ODIM 212 preferablyconverts the data into a standardized format for use by other modules inthe ETM 110.

The orders processed by the ODIM 212 are stored in an ETM database 214.Data in the database 214 are preferably accessible to the other modulesin the ETM 110. In addition, the other modules in the ETM 110 can storeother data in the illustrated database 214 or other databases as may berequired during normal operation.

In a preferred embodiment, an indications module 216 transmitsinformation about orders received by the ETM 110 among the varioustraders based upon filtering criteria established by the traders and/orthe ETM. This information is transmitted among the traders in the formof non-binding indications.

Based upon these indications, traders can enter into negotiations withother traders through a negotiation module 218. The negotiation module218 facilitates negotiations between traders using trading systems andhaving contra interests. In one embodiment, at least parts of thenegotiations are conducted anonymously, in order to limit the spread ofinformation about the traders' activities.

A market data module 220 receives real-time and other market data froman input 222. The market data module 220 provides the market data to thenegotiation module 218 and to the traders. The traders preferably usethe market data during the negotiations to determining market prices forthe securities.

A transaction history module 224 records transactions performed by theETM 110 in the database 214. The transaction history module 224 alsopreferably records other data processed by the ETM 110 including, forexample, information about orders received from and sent to the tradingsystems 112 and the negotiations conducted (successful or not). Thismodule 224 is preferably used to audit the transactions conducted on theETM 110.

A trader authentication module 226 authorizes and authenticates traderswho log into the ETM 110 in order to perform trading negotiations and/orother functions. In one embodiment, the trader authentication module 226stores authentication information, such as a login ID/password pair inthe database 214. The trader authentication module 226 also preferablystores profiles for the registered traders.

Other modules that may be present in the ETM 110 include load monitoringmodules for monitoring the load on various servers comprising the ETM,fault tolerance modules for providing fault tolerance to the ETM,security modules for preventing and detecting security violations on theETM, and back office modules for providing back office functionality.These modules are not shown in FIG. 12 in order to avoid unnecessarilycomplicating the figure.

FIG. 13 is a lower-level block diagram illustrating a trading system 112like those illustrated in FIG. 11. Those of ordinary skill in the artwill recognize that FIG. 13 illustrates only one possible embodiment ofa trading system 112 and alternative embodiments of the trading systemexist. FIG. 13 illustrates three workstations 310A, 310B, 310C coupledto an OMS server 312 via a network 314. The workstations 310 arepreferably general- or specific-purpose computer systems executingspecialized software for facilitating trading of securities. Althoughonly three workstations 310 are illustrated, a trading system 112 canhave any practical number of workstations.

In a typical trading system that interacts with the ETM 110, eachworkstation 310 executes a trader OMS interaction module 316 (TOIM) forfacilitating interactions with the OMS server 312. In this typicaltrading system, the TOIM 316 allows a trader to add, delete, or modifyopen or contemplated orders stored in the OMS database 114. Contemplatedorders may be stored in the OMS database 114, for example, because thetrader intends to execute certain transactions in stages, or because thecontemplated transactions are desirable only if the market prices of thesecurities to be traded are within a certain range (e.g., limit orders).Therefore, such orders serve as placeholders indicating the totalquantity of a security that a trader wishes to transact and conditionsfor transacting other orders; other data in the database 114 indicatethe quantity of the security that has been transacted to date.

Each workstation 310 executes an ETM interaction module 318 (EIM) forfacilitating interactions with the ETM 110. In alternative embodimentsof the present invention, the EIM 318 is incorporated into the TOIM 316or other modules on the workstation 310. The EIM 318 allows a trader tosend information to the ETM 110 and view and respond to informationreceived from the ETM 110. Typically, the received information includesinformation about orders (through the indications module 216) and orders(through the negotiation module 218) that the ETM 110 receives fromother traders or trading institutions. The trader uses the EIM 318 toenter into and transact negotiations to buy and/or sell securitiesthrough the ETM 110.

The network 314 connects the workstations 310 to the OMS 312 and toexternal networks such as the network in communication with the ETM 110.The network 314 can utilize any networking technology that supportsbi-directional transfer of data among the OMS 312, workstations 310, andexternal networks. In a typical embodiment, the network 314 is a privatelocal area network (LAN) installed at a financial institution andinterfacing with one or more external gateways. In alternateembodiments, the network may be wireless, connect devices over a widearea, and/or at least partially carry data over a public network (suchas the Internet). Other network components, such as a firewall, may alsobe present. Those of ordinary skill in the art will recognize that manydifferent types of networks can perform the functionality describedherein.

The OMS 312 is preferably comprised of one or more computer systems forexecuting and maintaining an order management system. The OMS 312receives instructions from the workstations to create, modify, and/ordelete orders and updates the database 114 accordingly. Softwareproviding the functionality of the OMS 312 is well known in the art.Commercial OMS software packages are available from The MacGregor Group,Eze Castle Software, Advent Software, and Decalog, to name but a few. Inaddition, some trading institutions utilize custom OMS software.

As described above, the database 114 holds data representative of open,contemplated, or completed orders to buy and/or sell securities. FIG. 14is a diagram illustrating a data record 400 stored in the database 114to identify an order according to one embodiment of the presentinvention. Different OMS systems utilize different order data recordsand, therefore, it should be understood that FIG. 14 illustrates onlyone possible data record. However, many OMS systems store the samegeneral information and the illustrated order data record 400 isintended to represent a typical order data record for an OMS system.

The order data record 400 has multiple fields, each field holdingdifferent information about an order. The Order ID field 410 preferablyholds a value uniquely identifying the order associated with the datarecord 400. Similarly, the Trader ID field 412 preferably holds a valueuniquely identifying the trader or other person who placed the order.The Order Status field 414 identifies whether the order is open,contemplated, completed, canceled, or any other possible status. Thenext field, Order Last Update Time 416, preferably holds a timestampthat identifies the last time that the data record 400 was modified inany way. This field 416 is useful for determining whether the mostrecent version of the data record 400 has been considered.

The Transaction Type field 418 preferably indicates whether the datarecord 400 corresponds to an order to buy or sell a security. TheSecurity Symbol field 420 preferably uniquely identifies the security tobe transacted. The Security Symbol field 420 can hold, for example, aCommittee on Uniform Securities Identification Procedures (CUSIP)number, a ticker symbol, or any other identifier of the security. TheSecurity Type field 422 is preferably used to interpret the other datain the data record 400 according to the given security type. Forexample, treasury bills are priced in terms of a discount to face value;inherent in the pricing formula is the yield that would be obtained ifthe bill were held to maturity. In contrast, equity securities arepriced in actual per-share values. The information in the Security Typefield 422 can also be used to filter out certain types of securities.

The Order Type field 424 preferably indicates whether the order is amarket or a limit order, although the field can also indicate otherorder types. If the order is a limit order, the Limit Price Field 426preferably identifies the price set by the trader.

The Total Order Size field 428 preferably identifies the actual numberof shares that the trader desires to transact. The Quantity PlacedElsewhere field 430 is a value either equal to or less than the value inthe Total Order Size field 428. In an embodiment of the presentinvention, the ETM 110 uses the values of these two fields 428, 430 todetermine a quantity of a security, if any, that are available to betransacted by the ETM.

Preferably, the OMS 312 allows for the possibility that trading a largequantity of a given security may occur over several days at severaldifferent venues. For example, to fill an order to buy 1,000,000 sharesof IBM, a trader may need to place an order for 300,000 shares with onebroker, and record numerous executions of portions thereof until thefull 300,000 shares placed with that broker are purchased. If the brokercannot provide additional shares at a suitable price, the trader maythen place an additional quantity, up to the 700,000 shares remaining tobe purchased, via another broker, electronic marketplace, or othervenue. Preferably, the broker enters a placement record into the OMSdatabase 114 to indicate that the trader anticipates executing a portionof the order through the second venue. This second venue may also fillthe quantity it was asked to provide in several executions. Thus, anorder can have one or more placements and each placement can have one ormore executions associated with it.

FIG. 15 is a diagram illustrating a placement record 500 preferablystored in the OMS database 114 to indicate a placement of an order at aparticular venue. The Order ID field 510 preferably holds a value thatuniquely identifies the order associated with the placement. The OrderID field 510 ties the placement information to the overall order. Thus,all placements for the same order preferably have the same value in thisfield 510. The Broker field 512 preferably contains an alphanumericvalue identifying the venue associated with the placement record.Lastly, the Quantity Placed with Broker field 514 preferably lists theportion of the total order size that is placed for fulfillment throughthe venue.

When a transaction is executed in a specified venue, such as the ETM110, a corresponding execution record is preferably stored in the OMSdatabase 114. FIG. 16 is a diagram illustrating an execution record 600according to an embodiment of the present invention. An execution IDfield 608 preferably holds a value identifying the particular execution.As before, the Order ID field 610 preferably holds a value that uniquelyidentifies the order associated with the execution and all executionsfor the same order preferably have the same value in this field 610. TheBroker field 612 preferably contains an alphanumeric value identifyingthe venue that performed the execution. The Quantity Executed field 614preferably specifies the number of securities transacted in thisexecution while the Price field 616 specifies the price at which thesecurities were executed. The Timestamp field 618 preferably records thetime at which the execution took place.

The OMS interfacing module (OIM) 320 is in communication with the OMSdatabase 114 via the network 314 or a direct connection. In alternativeembodiments, the OIM 320 is in communication with the OMS 312 and/or theworkstations 310. The OIM 320 is also in communication with the ETM 110via an external gateway or some other form of network connection. Inanother alternative embodiment, the OIM 320 is integrated into the ETM110 and is remote from the OMS 312, although some functionality ispresent at the OMS in order to provide OMS data to the OIM.

In a preferred embodiment, the OIM 320 includes a computer systemstoring and executing software for performing the functionalitydescribed herein. In an alternative embodiment, the OIM 320 executes onthe same computer system as the OMS 312. In one embodiment, the OIM 320includes an OMS database interaction module 322 for interacting with theOMS database 114. The OMS database interaction module 322 reads recordsstored in the OMS database 114 and, in a preferred embodiment, createsand modifies data records stored in the OMS database 114. In oneembodiment, the OMS database interaction module 322 directly accessesthe OMS database 114 and in another embodiment it sends commands to anapplications programming interface (API) in the OMS 312 for accessingthe database.

The OIM 320 also preferably includes an ETM communication module 324 forcommunicating with the ETM 110. In one embodiment, the ETM communicationmodule 324 automatically provides selected data records in the OMSdatabase 114 to the ETM 110 and, in a preferred embodiment, receivesdata and/or instructions from the ETM. In addition, the OIM 320 alsopreferably includes a data record conversion module 326 for modifyingthe format of the data records sent to and/or received from the ETM 110and a filtering module 238 for filtering out specified orders bysecurity type, security name, order type, order quantity, order price,or some other factor or category, so that filtered orders are nottransmitted to the ETM.

FIG. 17 is a flow diagram illustrating actions performed by anembodiment of the present invention when a trader logs on to the ETM110. Although the actions of FIG. 17 and subsequent figures areattributed herein to the OIM 320, one of ordinary skill in the art willrecognize that all or some of the actions can be carried out by otherentities.

Preferably, the OIM 320 waits 710 until a trader logs on to the OMS 312before transmitting data records for that trader to the ETM 110. In oneembodiment, the ETM 110 sends a message to the OIM 320 when a trader atthe institution in which the OIM 320 resides logs into the ETM. The OIM320 interprets this message as a sign to commence receiving orders. Inother embodiments of the present invention, the OIM 320 uses othertechniques, such as querying the OMS database 114 for specific entries,listening for an inter-process message sent by the OMS 312, pollingindividual trader workstations 310, or implementing a timer-basedalgorithm, to determine that a trader has logged on to the OMS 312.

Once a determination 710 is made that a trader has logged on to the OMS312 the OIM 320 retrieves 712 data records about orders suitable fortransmission to the ETM from the OMS database 114. In one embodiment ofthe present invention, all open orders are suitable for transmission tothe ETM 110. In other embodiments of the present invention, the OIM 320,through the filtering module 328, makes the determination of suitableorders based on other criteria, such as the security type (e.g., stockor bond), security name (e.g., IBM or T), order type (e.g., market orlimit order), order quantity, and/or order price.

If necessary, the data record conversion module 326 within the OIM 320preferably converts 714 the data records retrieved from the OMS database114 into a standardized format understood by the ETM 110. As describedabove, the functionality of the data record conversion module 326 canalso be performed by the ODIM 212 in the ETM 110. Alternativeembodiments of the present invention may send the data recordsindividually or in multiple batches. The data transmitted to the ETM 110depend on factors such as the types of securities being traded, and/orthe fields required in order to accurately trade such securities.

FIG. 18 is a flow diagram illustrating the actions performed by anembodiment of the present invention after a trader has logged on to theOMS during the trading day. The actions of FIG. 18 are preferablyautomatically performed multiple times during the trading day.Initially, the OIM 320 determines 810 whether the contents of the OMSdatabase 114 have changed. The OIM 320 can perform this step by, forexample, polling the database 114 at regular, near-real-time intervals,querying the database for contents of specified fields such astimestamps, and/or listening for network or specific interprocesscommunication message traffic.

If the database has changed, the OIM 320 preferably determines whetherthe change should be transmitted to the ETM 110. Because typical OMS'sare complex and multi-featured, and because securities of types nothandled by the ETM 110 may be traded using the OMS 312, some changes tothe OMS database 114 do not necessitate a transmission of updated datato the ETM 110. Thus, the OIM 320 determines 812 whether the change tothe database 114 reflects a new order of a type that is traded in theETM 110. If so, then the OIM 320 retrieves 816 the pertinent data forthe order from the database 114. If the change does not reflect a neworder, then the OIM 320 preferably determines 814 whether the databasechange pertains to a modification of an existing order that has alreadybeen sent to the ETM 110. If so, the OIM 320 retrieves 818 the datarecords corresponding to the modified order from the database 114. Oncethe appropriate data records, if any, are retrieved from the database,the OIM 320 preferably converts 820 the data records into theappropriate format and transmits the records to the ETM 110 as describedabove with respect to FIG. 17.

FIG. 19 is a flow diagram illustrating the actions performed by anembodiment of the present invention when the OMS database 114 is updatedin response to a trade executed by the ETM 110. The illustrated stepscan be performed each time a trade is executed, or in batch. However,the steps are preferably performed frequently enough so that the OMSdatabase 114 is updated in substantially real-time.

The OIM 320 initially determines 910 whether an execution occurred inthe ETM 110 involving an order in the OMS 312 associated with the OIM.The step may be performed, for example, by receiving a message from theETM 110 identifying a particular execution that occurred at the ETM, byfiltering a list of all executions or other data from the ETM forexecutions listed in the OMS 312, or by periodically polling the ETM forperformed executions.

If an execution occurred in the ETM 110 involving an order in the OMS312 associated with the OIM 320, the OIM receives 912 information fromthe ETM describing the execution. This information includes, forexample, the type, amount, and price of securities traded, the time ofexecution, and/or information identifying the original order in the OMSdatabase 114 on which the execution was based. The OIM 320 converts 914the received information about the execution into the format used by theOMS 312. Then, the OIM 320 updates 916 the OMS database 114 with theconverted execution data. As a result of these steps, the OMS 312 isupdated automatically and transparently to reflect executions performedat the ETM 110. The executions appear to the OMS 312 as typical tradesconducted at another broker.

In summary, the present invention includes an electronic tradingmarketplace that generates liquidity, at least in part, by receivingorder information directly from the databases of OMS systems at tradinginstitutions. Since orders are extracted from the OMS databasesautomatically, and information about executed orders is inserted intothe databases automatically, the OMS databases “see” the marketplace as“just another market intermediary.” Moreover, traders are able toconduct trades in the electronic marketplace without any duplicativemanual efforts.

The above description is included to illustrate the operation of thepreferred embodiments and is not meant to limit the scope of theinvention. The scope of the invention is to be limited only by thefollowing claims. From the above discussion, many variations will beapparent to one skilled in the relevant art that would yet beencompassed by the spirit and scope of the invention.

1. (canceled)
 2. A method comprising: receiving, by a marketplace, afirm order for a financial instrument from a broker participant of themarketplace, in which the firm order defines a side of a trade for thefinancial instrument, and in which the firm order includes an order toexecute the trade without additional authorization from the brokerparticipant; based on the received information, determining whether toapply a filter to orders before transmission of order queries; inresponse to receiving the firm order by the marketplace, transmitting anorder query identifying the firm order from the marketplace to aplurality of participants of the marketplace, in which each of theplurality of participants includes a respective order management system,in which each respective order management system is configured to storesecurely information about a plurality of order interests associatedwith the respective participant without revealing the interests outsideof the respective participant, in which each of the plurality ofparticipants includes a module configured to securely interface with arespective order management system of the respective participant; inresponse to receiving a respective order query by a respectiveparticipant of the plurality of participants, determining, by therespective module configured to securely interface with the respectiveorder management system of the respective participant, that a matchingorder that matches the firm order is stored in the respective ordermanagement system associated with the respective participant withoutrevealing information about respective trading interests of therespective participant outside of the respective participant; inresponse to the determination, providing, by the respective module ofthe respective participant, a request for acceptance of the firm orderwithout revealing information about respective trading interests of therespective participant outside of the respective participant; receiving,by the respective module of the respective participant, a positive replyto the request for acceptance; in response to receiving the positivereply, transmitting, from the respective participant to the marketplace,an indication that a trade fulfilling at least a part of the firm orderand at least a part of the matching order should be executed; receiving,by the marketplace, the indication that the trade should be executed;and in response to receiving the indication that the trade should beexecuted by the marketplace, facilitating execution of the tradefulfilling at least part of the firm order and at least part of thematching order without a further communication with the brokerparticipant.
 3. The method of claim 2, in which each of the plurality ofmodules of the participants is configured to interface with themarketplace and a user interface, and in which the act of determiningthat a matching order is stored in the respective order managementsystem associated with the respective participant is made based on achecking of orders currently stored in the respective order managementsystem, in which such check is made after receiving the respective orderquery.
 4. The method of claim 2, further comprising: receiving a secondindication, by the marketplace from a second respective participant,that a second trade fulfilling at least the part of the firm order andat least a part of a second matching order should be executed; andbefore facilitating the execution of the trade, determining, based on arate of activity associated with the respective participant and thesecond respective participant, that the respective participant haspriority over the second respective participant, and in whichfacilitating the execution includes facilitating the execution inresponse to determining that the respective participant has priority. 5.The method of claim 2, in which transmitting the order query includestransmitting respective indications to each of the participants in anorder based on a respective customer size of each respective participantso that the order query is transmitted to larger customers beforesmaller customers.
 6. The method of claim 2, further comprising:receiving, by a second respective participant, a respective order queryfrom the marketplace; in response to receiving, determining, by a secondrespective module configured to securely interface with a second ordermanagement system of the second respective participant, that there is nomatching order in the respective second order management systemassociated with the second respective participant without revealinginformation about respective trading interests of the second respectiveparticipant outside of the second respective participant; in response todetermining by the second respective participant, suppressing evidenceof the determining by the second respective participant.
 7. The methodof claim 6, in which suppressing evidence includes preventing a reply tothe order query from being sent to the marketplace from the secondrespective participant.
 8. The method of claim 7, in which the methodfurther comprises: determining, by the marketplace, that no reply to theorder query was received from the second respective participant; and inresponse to determining that no reply was received, preventing atransmission of at least one future order query to the second respectiveparticipant.
 9. The method of claim 8, in which preventing thetransmission includes preventing a transmission based on an underlyingsecurity of the order query and the future order query being the same.10. The method of claim 6, in which suppressing evidence includespreventing a request for acceptance of the firm order from beingprovided from a second respective module when such a request wouldotherwise have been provided.
 11. The method of claim 2, furthercomprising: suppressing, by the marketplace, evidence of the receivingthe positive reply, in which suppressing evidence includes notcommunicating the reply to anyone other than necessary parties for theexecution until after the execution, in which the necessary parties donot include the broker participant.
 12. The method of claim 2, in whichthe positive reply includes a binding acceptance of the firm order. 13.The method of claim 2, further comprising preventing communicationbetween the broker participant and the participant until after theexecution.
 14. The method of claim 2, further comprising: neverreceiving a negative reply to an order query, in which communicationincludes negotiation.
 15. The method of claim 2, in which eachparticipant is configured to not send any reply to the order query tothe marketplace if a respective determination that there is no matchingorder stored in a respective order management system associated with therespective participant is made.
 16. The method of claim 2, furthercomprising: receiving, by the marketplace from a second brokerparticipant, a second firm order for a second financial instrument; inresponse to the receiving from the second broker participant,determining, by the marketplace, that a matching firm order haspreviously been posted to the order book of the marketplace; and inresponse to the determining that the matching order has been posted,facilitating execution of an order fulfilling at least part of each ofthe second firm order and the matching firm order.
 17. The method ofclaim 2, in which each of the order queries and the reply aretransmitted using respective encrypted messages.
 18. The method of claim2, in which the method further comprises: before receiving the positivereply, periodically transmitting additional order queries identifyingthe firm order from the marketplace to each of the plurality ofparticipants.
 19. The method of claim 2, in which the respective moduleis configured to maintain secrecy of trading interests of the respectiveparticipant except to respond to the order query, and in which themarketplace is configured to maintain secrecy of the order query untilafter the trade is executed.
 20. A method comprising: receiving, by amarketplace, a firm order for a financial instrument from a brokerparticipant of the marketplace, in which the firm order defines a sideof a trade for the financial instrument, and in which the firm orderincludes an order to execute the trade without additional authorizationfrom the broker participant; based on the received information,determining whether to apply a filter to orders before transmission oforder queries; in response to receiving the firm order by themarketplace, transmitting an order query identifying the firm order fromthe marketplace to a plurality of participants of the marketplace, inwhich each of the plurality of participants includes a respective ordermanagement system, in which each respective order management system isconfigured to store securely information about a plurality of orderinterests associated with the respective participant without revealingthe interests outside of the respective participant, in which each ofthe plurality of participants includes a module configured to securelyinterface with a respective order management system of the respectiveparticipant; receiving, by the marketplace, from a respective moduleconfigured to securely interface with a respective order managementsystem of a respective participant of the plurality of participants, anindication that a trade fulfilling at least a part of the firm order andat least part of a matching order that is stored in the respective ordermanagement system should be executed; and in response to receiving theindication that the trade should be executed by the marketplace,facilitating execution of the trade fulfilling at least part of the firmorder and at least part of the matching order without a furthercommunication with the broker participant.
 21. An apparatus comprising:a processor; and memory storing instructions that, when executed, causethe processor to: receive, by a marketplace, a firm order for afinancial instrument from a broker participant of the marketplace, inwhich the firm order defines a side of a trade for the financialinstrument, and in which the firm order includes an order to execute thetrade without additional authorization from the broker participant;based on the received information, determine whether to apply a filterto orders before transmission of order queries; in response to receivingthe firm order by the marketplace, transmit an order query identifyingthe firm order from the marketplace to a plurality of participants ofthe marketplace, in which each of the plurality of participants includesa respective order management system, in which each respective ordermanagement system is configured to store securely information about aplurality of order interests associated with the respective participantwithout revealing the interests outside of the respective participant,in which each of the plurality of participants includes a moduleconfigured to securely interface with a respective order managementsystem of the respective participant; receive, by the marketplace, froma respective module configured to securely interface with a respectiveorder management system of a respective participant of the plurality ofparticipants, an indication that a trade fulfilling at least a part ofthe firm order and at least part of a matching order that is stored inthe respective order management system should be executed; and inresponse to receiving the indication that the trade should be executedby the marketplace, facilitate execution of the trade fulfilling atleast part of the firm order and at least part of the matching orderwithout a further communication with the broker participant.